You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Marius Grama (JIRA)" <ji...@apache.org> on 2015/05/15 17:48:00 UTC

[jira] [Updated] (SOLR-6669) 401 is not explicitly handled when querying HttpSolrServer

     [ https://issues.apache.org/jira/browse/SOLR-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marius Grama updated SOLR-6669:
-------------------------------
    Attachment: SolrJSearcher.java

SolrJSearcher.java - sample solrj client code used to reproduce the issue.

> 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.2
>
>         Attachments: SOLR-6669_code_screenshots.zip, SolrJSearcher.java
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org