[
https://issues.apache.org/jira/browse/SOLR-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841485#comment-13841485
]
Uwe Schindler commented on SOLR-5532:
-------------------------------------
bq. My best guess is that people encountering this problem aren't using the
provided jetty server, and the server they are using (or some proxy in between
their client and the server) is re-writing the the header slightly. the fact
that the initial problem report here refers to port "8080" smells like i may be
on to something.
When thinking about this, I know for example that Oracle iPlanet webserver does
this! And iPlanet uses Catilina internally which is the servlet engine of
Tomcat...
> SolrJ Content-Type validation is too strict, 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
> Attachments: SOLR-5532-elyograg-eclipse-screenshot.png
>
>
> 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.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
