[
https://issues.apache.org/jira/browse/SOLR-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188249#comment-14188249
]
Magnus Lövgren commented on SOLR-5532:
--------------------------------------
I've upgraded from 4.4 to 4.10.1 and have been struggling somewhat with my code
that was affected by this change. Some observations that might be useful for
others too:
The patch relies on the "org.apache.http.entity.ContentType.parse" method. It
fails when parsing an empty string. That's fine (empty string should probably
not be seen as a valid type anyway). The caveat is that an empty string is
actually used as the "fallback" contentType if the response has no Content-Type
header! This would be the typical case if the response is a 401 (typically has
no Content-Type).
- In prior versions a 401 response threw a SolrException with code() 401
- Now a SolrServerException is thrown (caused by a
org.apache.http.ParseException). Hard to determine if it was due to bad
credentials (401).
To restore previous behaviour, you'd presumably add the
HttpStatus.SC_UNAUTHORIZED case to the switch and then throw a
RemoteSolrException (with code 401). In other words - fail early for 401
response (there's no content to parse anyway)
> SolrJ Content-Type validation is too strict for some webcontainers / proxies,
> breaks on equivilent content types
> ----------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-5532
> URL: https://issues.apache.org/jira/browse/SOLR-5532
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.6
> Environment: Windows 7, Java 1.7.0_45 (64bit), solr-solrj-4.6.0.jar
> Reporter: Jakob Furrer
> Assignee: Mark Miller
> Fix For: 4.6.1, 4.7, Trunk
>
> Attachments: SOLR-5532-elyograg-eclipse-screenshot.png,
> SOLR-5532.patch
>
>
> due to SOLR-3530, HttpSolrServer now does a string equivilence check between
> the "Content-Type" returned by the server, and a getContentTYpe() method
> declared by the ResponseParser .. but string equivilence is too strict, and
> can result in errors like this one reported by a user....
> ----
> I just upgraded my Solr instance and with it I also upgraded the solrj
> library in our custom application which sends diverse requests and queries to
> Solr.
> I use the "ping" method to determine whether Solr started correctly under the
> configured address. Since the upgrade the ping response results in an error:
> {code:xml}
> Cause: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Expected content type application/xml; charset=UTF-8 but got
> application/xml;charset=UTF-8.
> <?xml version="1.0" encoding="UTF-8"?>
> <response>
> <lst name="responseHeader"><int name="status">0</int><int
> name="QTime">0</int><lst name="params"><str name="df">searchtext</str><str
> name="echoParams">all</str><str name="rows">10</str><str
> name="echoParams">all</str><str name="wt">xml</str><str
> name="version">2.2</str><str name="q">solrpingquery</str><str
> name="distrib">false</str></lst></lst><str name="status">OK</str>
> </response>
> {code}
> The Solr application itself works fine.
> Using an older version of the solrj library than solr-solrj-4.6.0.jar (e.g.
> solr-solrj-4.5.1.jar) in the custom application does not produce this error.
> The Exception is produced in a Code block (_HttpSolrServer.java_, method
> _request(...)_, around. line 140) which has been introduced with version
> 4.6.0.
> Code to reproduce the error:
> {code}
> try {
> HttpSolrServer solrServer = new
> HttpSolrServer("http://localhost:8080/Solr/collection";);
> solrServer.setParser(new XMLResponseParser()); // this line is making
> all the difference
> solrServer.ping();
> } catch (Exception e) {
> e.printStackTrace();
> }
> {code}
> A global search for "charset=UTF-8" on the source code of solrj indicates
> that other functions besides "ping" might be affected as well, because there
> are several places where "application/xml; charset=UTF-8" is spelled without
> a space after the semicolon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
