[jira] Commented: (SOLR-443) POST queries don't declare its charset
[
https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554211
]
Andrew Schurman commented on SOLR-443:
--
Hmm... I just tested the latest patch on a different machine with Tomcat 6.0.14
and it does appear to work (I must have some sort of caching problem on my
other machine).
As for standards, I don't believe it's updated, but I found HTML
Internationalization RFC http://www.ietf.org/rfc/rfc2070.txt. On page 16, it
mentions that setting the charset with a content-type of
{{x-www-form-urlencoded}} should have the understanding that the URL encoding
of [RFC1738] is applied on top of the specified character encoding, as a kind
of implicit Content-Transfer-Encoding. In this case, it does seem valid to be
setting the charset on the post.
POST queries don't declare its charset
--
Key: SOLR-443
URL: https://issues.apache.org/jira/browse/SOLR-443
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.2
Environment: Tomcat 6.0.14
Reporter: Andrew Schurman
Priority: Minor
Attachments: solr-443.patch, solr-443.patch
When sending a query via POST, the content-type is not set. The content
charset for the POST parameters are set, but this only appears to be used for
creating the Content-Length header in the commons library. Since a query is
encoded in UTF-8, the http headers should also specify content type charset.
On Tomcat, this causes problems when the query string contains non-ascii
characters (characters with accents and such) as it tries to parse the POST
body in its default ISO-9886-1. There appears to be no way to set/change the
default encoding for a message body on Tomcat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-443) POST queries don't declare its charset
POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schurman updated SOLR-443: - Attachment: solr-443.patch Simple fix that will fix the issue for this case. I don't believe it will cause issues elsewhere within the java client. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554005 ] Andrew Schurman commented on SOLR-443: -- Haven't had a chance to test that, but I believe that would work also since we are only sending non-multipart POSTs anyways. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch, solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554062 ] Andrew Schurman commented on SOLR-443: -- I believe your right Yonik. I think when I was testing I forgot to remove a filter that I was using to convert the request into UTF8. I'm now testing again and it still appears to process the results inconsistently. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch, solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-355) Parsing mixed inclusive/exclusive range queries
Parsing mixed inclusive/exclusive range queries --- Key: SOLR-355 URL: https://issues.apache.org/jira/browse/SOLR-355 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.2 Reporter: Andrew Schurman Priority: Minor The current query parser doesn't handle parsing a range query (i.e. ConstantScoreRangeQuery) with mixed inclusive/exclusive bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-355) Parsing mixed inclusive/exclusive range queries
[ https://issues.apache.org/jira/browse/SOLR-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schurman updated SOLR-355: - Attachment: solr-355.patch Potential fix for revision 575064. Parsing mixed inclusive/exclusive range queries --- Key: SOLR-355 URL: https://issues.apache.org/jira/browse/SOLR-355 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.2 Reporter: Andrew Schurman Priority: Minor Attachments: solr-355.patch The current query parser doesn't handle parsing a range query (i.e. ConstantScoreRangeQuery) with mixed inclusive/exclusive bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
