I don't like the current 500. That's sharing the same conceptual space as NPE, bugs and other hard failures for which IT should be paged at 2:30 am.
5xx indicates that there is a problem with the server and that there is nothing the client can do, and also would typically be flagged by monitoring tools as a system problem. That's not true, often the query can be modified, or resubmitted of peak hours etc... The server is not compromised. 4xx indicates that "the client should correct their request" which is true if things are taking a long time because the request was dumb in the first place, but since that's entirely relative to the index and the hardware, it's unknowable from our perspective so it also feels wrong to send a 400, because it could be a perfectly fine request sent in the middle of a DOS attack... Not the client's fault. Stepping back a moment let's think about the request: it says "run this query for up to X milliseconds" ... the server did that successfully so really the response ought to be a success. So 206 Partial Content seems to make the most sense -Gus On Wed, Mar 20, 2024 at 2:06 PM Chris Hostetter <hossman_luc...@fucit.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. > > Devils avocate argument: it is an "unexpected condition" -- it's unepected > that the request wasn't able to be processed w/in the configured limits. > If you > expected that the request could *NOT* be processed, why send it w/those > limits? > > I'm -0 to using 503 because it's worded to very explicitly be a temporal > situation: failue "due temporary overload or scheduled maintenance" -- > those aren't *examples* of why a server MAY return 503, those are the > explict circumstances indicated by a 503 -- and neither one is directly > applicable for a query limit being exceeded. An otherwise idle server > might still fail a request with a query limit configured -- regardless of > wther the server is "overloaded" or down for "scheduled maintenance" -- > and there is no reason for a client to assume retrying a request with the > same query limits will succeed again in the future. > > > Bottom line for me: I'm fine w/changing the default response code to > anything -- as long as we make it configure. But i *strongly* urge us > not to use a non-standard error code that already has very specific, well > established, meaning with well known proxy software. > > > : 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 > : > > : > : > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
