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
