[ 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org