[
https://issues.apache.org/jira/browse/SOLR-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841379#comment-13841379
]
Hoss Man commented on SOLR-5532:
--------------------------------
bq. As far as i can tell from a quick check, the XML response writer (on the
server) has always included a space in it's Content-Type, and that doesn't seem
to have changed in 4.6, and the solrj expected XML Content-Type (on the client
parser) has always expected a space in the Content-Type, and that doesn't seem
to have changed in 4.6.
Ok, here's what i reallize now that i overlooked when i skimmed the old code
yesterday:
* the content type as written by the server has not changed
* the content type as written by the server, and the content type as parsed by
the client are in fact 100% identical (same variable)
* what's new in 4.6 is the check to verify that the ContentType's are equal (In
my previous skim i totally overlooked that the code throwing this error is new
in 4.6, added as part of SOLR-3530
That still, however, doesn't explain the bug report, and why elyograg and i
can't reproduce, and why the solrj xml tests aren't reproducing it --
specifically: and what's happening to the space character to cause this
exception.
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.
Either way: we should fix how the Content-Type comparison is done.
> HttpSolrServer does not accept content type of "ping" response
> --------------------------------------------------------------
>
> Key: SOLR-5532
> URL: https://issues.apache.org/jira/browse/SOLR-5532
> Project: Solr
> Issue Type: New Feature
> 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
>
>
> 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]
