SolrException error code not being propagated to the HTTP response

[Matthias Pigulla <mp...@webfactory.de>]

Dear solr-dev,

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.

The question I’d like to ask is if there is any particular reason why this leads to a HTTP 500 status code.

Wouldn’t something like e. g. HTTP 400 (Bad Request) make more sense? At least in my case, it would make processing in the downstream systems (that have to deal with Solr’s response) much easier if I could recognize this class of errors.

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.

So, my question is: Is there a good reason why the status code from the `SolrException` is not being propagated to the HTTP response in a central location? Does this deserve a bug, or are there any good reasons why it cannot easily be fixed or was even designed this way?

Thanks!
-mp.

Re: SolrException error code not being propagated to the HTTP response

[Jan Høydahl <ja...@cominvent.com>]

It is because the exception happens inside a constructor - so it gets mapped to a 500.

I tried to move the parsing from constructor to init() and then we get a proper 400 error

> HTTP ERROR 400 {metadata={error-class=org.apache.solr.common.SolrException, root-error-class=org.apache.solr.common.SolrException}, msg=URLDecoder: Invalid character encoding detected after position 22 of query string / form data (while parsing as UTF-8), code=400}

The patch is here https://github.com/apache/solr/pull/648

Please create a JIRA issue for this bug, and we can discuss it further there.

Jan


> 17. feb. 2022 kl. 15:33 skrev Matthias Pigulla <mp...@webfactory.de>:
> 
> Dear solr-dev,
>  
> 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.
>  
> The question I’d like to ask is if there is any particular reason why this leads to a HTTP 500 status code.
>  
> Wouldn’t something like e. g. HTTP 400 (Bad Request) make more sense? At least in my case, it would make processing in the downstream systems (that have to deal with Solr’s response) much easier if I could recognize this class of errors.
>  
> 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 <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.
>  
> So, my question is: Is there a good reason why the status code from the `SolrException` is not being propagated to the HTTP response in a central location? Does this deserve a bug, or are there any good reasons why it cannot easily be fixed or was even designed this way?
>  
> Thanks!
> -mp.