: 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
