[
https://issues.apache.org/jira/browse/SOLR-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-6669:
------------------------------
Fix Version/s: 5.1
Trunk
> 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
> 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
> Reporter: Magnus Lövgren
> Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-6669_code_screenshots.zip
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
