W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: AW: Use of Status Code 500

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
Message-Id: <1252003706.2392.14.camel@henriknordstrom.net>
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

> > 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.

Received on Thursday, 3 September 2009 18:49:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC