[
https://issues.apache.org/jira/browse/SOLR-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545689#comment-14545689
]
Marius Grama commented on SOLR-6669:
------------------------------------
I've tried to reproduce the scenario (see the attachment SolrJSearcher.java)
that you've exposed with the current version of the source code and there is no
issue seems not to be anymore present.
Calling a secured resource (I've used the
[SolrSecurity|https://wiki.apache.org/solr/SolrSecurity] guideline for applying
security on the techproducts example collection) without authentication data
throws now a RemoteSolrException with the code 401 and the mesage
{code:language=html}
Error from server at http://localhost:8983/solr/securedtechproducts: Expected
mime type application/octet-stream but got text/html. <html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 401 Unauthorized</title>
</head>
<body><h2>HTTP ERROR 401</h2>
<p>Problem accessing /solr/securedtechproducts/select. Reason:
<pre> Unauthorized</pre></p><hr /><i><small>Powered by
Jetty://</small></i><br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
</body>
</html>
{code}
I consider that this is no longer an issue in the current code base.
> 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
>
>
> 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
