: > We should probably separate business-related end-user errors (such as when
: > user submits empty query) and make it XML-like (instead of HTTP 400)
:
: Speaking as a former web spider maintainer, it is very important to keep
: the HTTP response codes accurate. Never return an error with a 200.
:
: If we want more info, return an entity (body) with the 400 response.
Surely there is value in distinguishing between errors that occur in
"Solr" at the HTTP abstraction layer and logical errors that occur in the
request handler?
it seems like there would definitely be some merrit in using the HTTP
response code only to indicate Solr's ability to successfully interpret
the URL and hand it off to a RequestHandler and an OutputWriter -- some
other mechanism would probably make sense for the RequestHandler to
indicate it could not perform it's function.
For example, these urls should probably cause Solr to generate a 4xx HTTP
status...
http://host:9999/FOOBALOO
http://host:9999/select
...and any URL could concievably generate a 500 status if the
schema.xml or solrconfig.xml can't be parsed, or if the index dir can't be
opened; but if a valid request comes in for something like this...
http://host:9999/select?qt=bob&id=foo
...and there is a RequestHandler named "bob" but bob's logic is to lookup
a document whose uniqueKey is the id param, and then foreach value of some
field in that doc, execute another search and return all of hte results --
what should bob do if the id param is specified (as in the example URL)
but no document with that ID can be found?
right now, the only means bob has to indicate an error is either to put
an arbitrary "error code" Object in the SolrResponse, or to generate an
execption, which results in either a 4xx or a 5xx error code (i forget
which at the moment) ... but has an error really occured at the HTTP
layer? ... it seems to me like this is the kind of case where the HTTP
status code should be 200, but the body of the HTTP response should
include some other data indicating a high level failure -- and that should
be included in a standard way that is independent of which RequestHandler
triggered it.
(abstractly i'm thinking along the same lines as why "good" web based
applications don't generate 404 error pages when you fill out a form
improperly, they generate 200 pages, but the HTML tells you there was a
problem -- since we control the output format, we can say that it will
contain specially indicator of success/failure -- but it's not hte same
thing as the HTTP status.
-Hoss
