lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5532) SolrJ Content-Type validation is too strict, breaks on equivilent content types
Date Fri, 06 Dec 2013 16:59:35 GMT

    [ https://issues.apache.org/jira/browse/SOLR-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841425#comment-13841425
] 

Mark Miller commented on SOLR-5532:
-----------------------------------

bq. the content type as written by the server, and the content type as parsed by the client
are in fact 100% identical (same variable)

I was careful to ensure that.

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


Mime
View raw message