I still think 503 is appropriate when timeAllowed is exceeded. The service requested is a reponse within the set time. That service is not available. Here are the RFC definitions of 500 and 503. Exceeding timeAllowed isn’t an “unexpected condition”, it is part of the normal operation of that limit.
6.6.1. 500 Internal Server Error The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.1 6.6.4 503 Service Unavailable The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.4 Solr could even return 503 with a message of “timeAllowed exceeded”. I spent about a decade working on a search engine with an integrated web spider. Accurate HTTP response codes are really useful. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Mar 19, 2024, at 3:12 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > > Agree on all of Uwe's points below > > I think 500 is the most appropriate for exceeding QueryLimits -- > unless/until we decie we want Solr to start using custom response codes in > some cases, but in that case i would suggest we explicitly *avoid* using > 504, 524, & 529 precisely because they already have specific meanings in > well known HTTP proxies/services that don't match what we're talking about > here. > > As far as one of David's specific observations... > > : > ideal IMO because Solr's health could reasonably be judged by looking > : > for 500's specifically as a sign of a general error that service > : > operators should pay attention to. > > Any client that is interpreting a '500' error as a *general* indication of > a problem with Solr, and not specific to that request, would not be > respecting the spec on what '500' means. *Some* '5xx' are documented > to indicate that there may be a general problem afflicting the > server/service as a whole (notably '503') but most do not. > > But i also think that if we really want to cover our basis -- we can > always make it configurable. Let people configure Solr to return > 500, 400, 418, 666, 999, ... wtf they want ... but 500 is probably the > best sane default that doesn't carry around implicit baggage. > > : 524 or 504 both refer to timeouts, but both are meant for proxies (so > reverse > : proxy can't reach the backend server in time). So both of them do not match. > : > : 408 is "request timeout", but that's client's fault (4xx code). In that case > : its a more technical code because it also requires to close the connection > and > : not keep it alive, so we can't trigger that from Servlet API in a correct > way. > : > : 503 does not fit well as Solr is not overloaded, but would be the only > : alternative I see. Maybe add a new Solr-specific one? Anyways, I think 500 > : seems the best response unless you find another one not proxy-related. > : > : Uwe > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org >
