I'm glad I raised this topic -- great feedback from all of you! I suppose we could indeed use a new/unused response code. Making it configurable seems fine but I'd only want to support arcane things like that in the most basic way, e.g. using the new EnvUtils.
Walter's response really resonates with me -- 503 "temporary overload" wording is a reasonable characterization of exceeding a timeout in practice, at least a good proportion of the time. Perhaps less clear when the user's query is really expensive and there's ample resources to finish it. But a timeout's existence is largely to prevent resource exhaustion (overload) so this distinction of *is* overloaded vs. protecting ourselves from such is splitting hairs needlessly IMO. On Tue, Mar 19, 2024 at 6:54 PM Walter Underwood <wun...@wunderwood.org> wrote: > > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
