- From: Svensson, Lars <l.svensson@d-nb.de>
- Date: Thu, 3 Sep 2009 16:22:04 +0200
- 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 <mailto:julian.reschke@gmx.de>scripsit: >>> 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. OK. > 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... Thanks, Lars -- Dr. Lars G. Svensson Deutsche Nationalbibliothek Informationstechnik Adickesallee 1 60322 Frankfurt http://www.d-nb.de/
Received on Thursday, 3 September 2009 14:22:45 UTC