[SOLR-6669] 401 is not explicitly handled when querying HttpSolrServer

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Cannot Reproduce
• Affects Version/s: 4.7
• Fix Version/s: 5.2, 6.0
• Component/s: SolrJ

Environment

solr-solrj-4.10.1.jar
tested with:
Windows 7, 6.1, amd64
Java HotSpot(TM) 64-Bit Server VM, 1.7.0_67, Oracle Corporation
and
Linux, 3.11.6-4-default, amd64
Java HotSpot(TM) 64-Bit Server VM, 1.7.0_72, Oracle Corporation

• Assignee: Unassigned
• Reporter: Magnus Lövgren
• Created: 29/Oct/14 14:00
• Updated: 13/Dec/18 11:53
• Resolved: 13/Dec/18 11:53

Description

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):

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) {
   ...
}

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:

1. The HttpClient executes the method and gets the response
   • The response is a 401/Unauthorized
   • 401 response has no Content-Type header
2. Since there are no content type, it will be set to empty string as fallback
3. 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
4. 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

case HttpStatus.SC_UNAUTHORIZED:
   throw new RemoteSolrException(httpStatus, "Server at "
      + getBaseURL() + " returned non ok status:" + httpStatus
      + ", message:" + response.getStatusLine().getReasonPhrase(),
       null);

...and it would perhaps be appropriate to handle the content type "fallback" in some other way than setting it to an empty string?