Subject: Use of Status Code 500

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 2 Sep 2009 08:53:28 +0200

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. This caused problems when we upgraded
our Tomcats to use load-balancing, since the mod-jk now thinks the
Tomcat returning SC 500 isn't responding properly and switches the
session to the other Tomcat instance. If the user now repeats the same
action and the communication error is still there -- leading to a 500
again--, the mod-jk will block both Tomcats and the user cannot login
again.

So: Is 500 the correct error code to send in this case and -- if not --
which one should I use?

Thanks in advance,

Lars

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 02 Sep 2009 11:02:07 +0200

ons 2009-09-02 klockan 08:53 +0200 skrev Svensson, Lars:
> errror with one of the subsystems.

Sounds reasonable to me. 500 is "unspecified server failure".

>  This caused problems when we upgraded
> session to the other Tomcat instance.

Also sounds reasonable for a load balancer configured to hide server
errors.

but it should not mark the server permanently down/malfunctioning only
because of an isolated failure..

>  If the user now repeats the same

Sounds like a mod-jk defect to me.

> So: Is 500 the correct error code to send in this case and -- if not --

500 is quite suitable. Or alternatively 503.

Regards
Henrik

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 3 Sep 2009 16:02:47 +0200

In litteris suis de Mittwoch, 2. September 2009 11:02, Henrik Nordstrom
<mailto:[email-masked]>scripsit:

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

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?

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

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?

Thanks in advance,

Lars
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationstechnik
Adickesallee 1
60322 Frankfurt
http://www.d-nb.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Sep 2009 16:15:16 +0200

> an error page serving SC 200 and the error message would be more

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.

> haven't really found anything in the spec...

You can send details in the response body (but I assume you already do 
that :-).

> ...

BR, Julian

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 3 Sep 2009 16:22:04 +0200

In litteris suis de Donnerstag, 3. September 2009 16:15, Julian Reschke
<mailto:[email-masked]>scripsit:

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

OK.

> Status 200 would mean that automated applications get content

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

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

Thanks,

Lars

---

From: David Morris <[email-masked]>
Date: Thu, 3 Sep 2009 07:33:14 -0700 (PDT)

> in the other Tomcat instance, the user never gets to see it...

Uh ... that sounds like a violation of the HTTP protocol ... a load 
balancer essentially retrying a request once any bytes are sent to the
server. Are you sure it isn't the *next* request the LB sends to the 
alternate server?

Dave Morris

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 03 Sep 2009 20:48:26 +0200

tor 2009-09-03 klockan 16:02 +0200 skrev Svensson, Lars:

> 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

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.

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

> 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