[
https://issues.apache.org/jira/browse/SOLR-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Pigulla updated SOLR-16019:
------------------------------------
Description:
When I make a request to an URI like {{{}/solr/my_core/query?q=%C0{}}}, I get a
HTTP 500 status code with a stack trace originating at
{{org.apache.solr.common.SolrException: URLDecoder: Invalid character encoding
detected after position 2 of query string / form data (while parsing as UTF-8)}}
{{at
org.apache.solr.servlet.SolrRequestParsers.decodeChars(SolrRequestParsers.java:421)}}
{{…}}
The obvious reason is that the {{q}} parameter value looks like the first byte
in a multibyte utf-8 sequence, but that sequence is incomplete/invalid. -I have
seen a few more instances of this in our monitoring, also with different places
where the problem surfaces.- [Other issues unrelated, will file separate
issues.]
Instead of the HTTP 500 status code, something like e. g. HTTP 400 (Bad
Request) would be more appropriate. It would also make processing in downstream
systems (that have to deal with Solr’s response) much easier if this class of
errors could be recognized.
Also, if I look at the place where the exception is being thrown
([https://github.com/apache/solr/blob/releases/lucene-solr/7.7.3/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java#L419-L422]),
care was taken to use the `ErrorCode.BAD_REQUEST` status. This information,
however, seems to be lost along the way.
was:
When I make a request to an URI like {{{}/solr/my_core/query?q=%C0{}}}, I get a
HTTP 500 status code with a stack trace originating at
{{org.apache.solr.common.SolrException: URLDecoder: Invalid character encoding
detected after position 2 of query string / form data (while parsing as UTF-8)}}
{{at
org.apache.solr.servlet.SolrRequestParsers.decodeChars(SolrRequestParsers.java:421)}}
{{…}}
The obvious reason is that the {{q}} parameter value looks like the first byte
in a multibyte utf-8 sequence, but that sequence is incomplete/invalid. I have
seen a few more instances of this in our monitoring, also with different places
where the problem surfaces.
Instead of the HTTP 500 status code, something like e. g. HTTP 400 (Bad
Request) would be more appropriate. It would also make processing in downstream
systems (that have to deal with Solr’s response) much easier if this class of
errors could be recognized.
Also, if I look at the place where the exception is being thrown
([https://github.com/apache/solr/blob/releases/lucene-solr/7.7.3/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java#L419-L422]),
care was taken to use the `ErrorCode.BAD_REQUEST` status. This information,
however, seems to be lost along the way.
> UTF-8 parsing errors for parameters should cause a HTTP 400 status code, not
> 500
> --------------------------------------------------------------------------------
>
> Key: SOLR-16019
> URL: https://issues.apache.org/jira/browse/SOLR-16019
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Matthias Pigulla
> Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I make a request to an URI like {{{}/solr/my_core/query?q=%C0{}}}, I get
> a HTTP 500 status code with a stack trace originating at
> {{org.apache.solr.common.SolrException: URLDecoder: Invalid character
> encoding detected after position 2 of query string / form data (while parsing
> as UTF-8)}}
> {{at
> org.apache.solr.servlet.SolrRequestParsers.decodeChars(SolrRequestParsers.java:421)}}
> {{…}}
> The obvious reason is that the {{q}} parameter value looks like the first
> byte in a multibyte utf-8 sequence, but that sequence is incomplete/invalid.
> -I have seen a few more instances of this in our monitoring, also with
> different places where the problem surfaces.- [Other issues unrelated, will
> file separate issues.]
> Instead of the HTTP 500 status code, something like e. g. HTTP 400 (Bad
> Request) would be more appropriate. It would also make processing in
> downstream systems (that have to deal with Solr’s response) much easier if
> this class of errors could be recognized.
> Also, if I look at the place where the exception is being thrown
> ([https://github.com/apache/solr/blob/releases/lucene-solr/7.7.3/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java#L419-L422]),
> care was taken to use the `ErrorCode.BAD_REQUEST` status. This information,
> however, seems to be lost along the way.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
