Magnus Lövgren created SOLR-6669:
------------------------------------
Summary: 401 is not explicitly handled when querying HttpSolrServer
Key: SOLR-6669
URL: https://issues.apache.org/jira/browse/SOLR-6669
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 4.7
Reporter: Magnus Lövgren
Priority: Minor
This is a regression, likely caused by SOLR-5532 (see comments at the end in
that JIRA).
I use solrj and HttpSolrServer in my web application (deployed in Tomcat 7).
Recently I updated Solr from 4.4. to 4.10.1 and it seems 401 is not handled
properly anymore when using a custom HttpClient.
The essentials of my code (that was working in 4.4):
{code}
String theSolrBaseURL = ...
HttpClient theHttpClient = ...
SolrQuery theSolrQuery = ...
try {
SolrServer solrServer = new HttpSolrServer(theSolrBaseURL, theHttpClient);
QueryResponse response = solrServer.query(theSolrQuery);
...
} catch (SolrException se) {
if (se.code() == HttpStatus.SC_UNAUTHORIZED) {
// Client is using bad credentials, handle appropriately
...
}
...
} catch (SolrServerException sse) {
...
}
{code}
The code should speak for itself, but the basic idea is to try to recover if
the client is using bad credentials. In order to do that I catch the
SolrException and check if the code is 401. This approach worked well in Solr
4.4.
However, this doesn't work when using Solr 4.10.1. The query method throws a
SolrServerException if the HttpClient is using bad credentials. The original
cause is a {{org.apache.http.ParseException}}.
The problem arises in the {{HttpSolrServer.executeMethod(HttpRequestBase,
ResponseParser)}} metod:
# The HttpClient executes the method and gets the response
#* The response is a 401/Unauthorized
#* 401 response has no Content-Type header
# Since there are no content type, it will be set to empty string as fallback
# Later on the mime type is extracted using
{{org.apache.http.entity.ContentType.parse(String)}} in order to handle charset
issues (see SOLR-5532)
#* This metod fails to parse empty string and throws a
{{org.apache.http.ParseException}}
# The intermediate caller {{QueryRequest.process(SolrServer)}} will catch the
exception and throw a {{SolrServerException}}
A potential fix would be to add a 401 case to the existing switch
{code}
case HttpStatus.SC_UNAUTHORIZED:
throw new RemoteSolrException(httpStatus, "Server at "
+ getBaseURL() + " returned non ok status:" + httpStatus
+ ", message:" + response.getStatusLine().getReasonPhrase(),
null);
{code}
...and it would perhaps be appropriate to handle the content type "fallback" in
some other way than setting it to an empty string?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
