We have a front application server that uses Solr to search our contents.
If the front application calls Solr with /select but missing q parameter,
Solr returns a stack trace with its response body, while we expect
XML response with an error message (& the stack trace in the XML).
Is it a feature?
If so, is the front server responsible about checking required params
before requesting to Solr, correct?
but the solution was that the front checked q parameter before sending.
We are hoping Solr returns a readable response produced by Response Writer
even if the front server sends wrong request to Solr,
but if it is a feature, we will validate params at the front.
We'd like to just confirm that.
: If the front application calls Solr with /select but missing q parameter,
: Solr returns a stack trace with its response body, while we expect
: XML response with an error message (& the stack trace in the XML).
: Is it a feature?
: If so, is the front server responsible about checking required params
: before requesting to Solr, correct?
generally speaking, clients should allways try to ensure that they only
send welformed requests -- the built in RequestHandlers can't function
without a "q" param, so i would say yes they should check that they have a
value for that param before sending the request to Solr. if you want
their to be a default value for the "q" param, you can configure it in the
at a broader level, you are correct - the error reporting is not very
clean. we are hoping to eventually fix that so the error reporting is
I'm lobbying to let the SolrDispatchFilter handle /select. The
SolrDispatchFilter passes the error code and message on to the servlet
container so it is formatted in the most standard way. It also only
includes a stack trace for 500 errors, not 400,403,etc. It uses: