- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Thu, 03 Sep 2009 20:48:26 +0200
- To: "Svensson, Lars" <l.svensson@d-nb.de>
- Cc: ietf-http-wg@w3.org
tor 2009-09-03 klockan 16:02 +0200 skrev Svensson, Lars: > Thanks for your reply. It turned out to be a bit different than I first > said: It's not a communication error that causes the malfunction, but a > bug in the application that causes an exception to be thrown when data > from the subsystem is processed. Would you still agree that SC 500 is > reasonable Yes, it's the "catch all" errorcode for servers to use when they somehow could not respond properly to the request and none of the other error codes describe the situation well or when the server do not want to be as specific about the error status. > or (since we know about the exception and can catch it) that > an error page serving SC 200 and the error message would be more > appropriate? No, not at all. 200 means success. Not suitable for error messages. Error messages should be 4xx or 5xx depending on the nature of the error. > > 500 is "unspecified server failure". > > If 500 is "unspecified", is there any way I can specify the error? I > haven't really found anything in the spec... By describing it in the response body, using whatever language you thing the requesting user may understand. > Finally: Do you (or anyone else on this list) know if there are any best > practices for those cases and -- if so -- where those are documented? How a application level gateway like that balancer should react on error is implementation specifc, and the case you describe is a thin balance between different error scenarios. It's very unlikely you will find a best practice that works for even 50%. as there is at least 4 very different error scenarios to deal with, each requiring different actions to cover up for the error as smoothly as possible. Regards Henrik
Received on Thursday, 3 September 2009 18:49:11 UTC