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

AW: AW: Use of Status Code 500

From: Svensson, Lars <l.svensson@d-nb.de>
Date: Thu, 3 Sep 2009 16:22:04 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA197298409B6FC1A@dbf-ex.AD.DDB.DE>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: <ietf-http-wg@w3.org>, "Henrik Nordstrom" <henrik@henriknordstrom.net>
In litteris suis de Donnerstag, 3. September 2009 16:15, Julian Reschke

>>> ons 2009-09-02 klockan 08:53 +0200 skrev Svensson, Lars:
>>>> At my place we're a bit unsure of the use of Status Code 500. One
>>>> of our apps (a distributed one) returns a SC 500 when there is a
>>>> communication errror with one of the subsystems.
>>> Sounds reasonable to me. 500 is "unspecified server failure".
>> 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, 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?
> OMG, no. 500 is *exactly* what you want in that case.


> Status 200 would mean that automated applications get content
> and assume
> everything is fine.

Yes, I though so too (although the risk is minimal, since the data is
protected through form authentication...).

>>> 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...
> You can send details in the response body (but I assume you already
> do that :-). 

Yes, I do, but since the load balancer catches the exception and kicks
in the other Tomcat instance, the user never gets to see it...


Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Adickesallee 1
60322 Frankfurt
Received on Thursday, 3 September 2009 14:22:45 UTC

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