W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: another approach to status codes, etc. in HTTP binding

From: Mark Baker <distobj@acm.org>
Date: Thu, 19 Jul 2001 10:21:12 -0700
To: christopher ferris <chris.ferris@east.sun.com>
CC: xml-dist-app@w3.org
Message-Id: <20010719141858.TYSQ3894.tomts7-srv.bellnexxia.net@SPARTICUS>
7/19/2001 3:20:30 AM, christopher ferris <chris.ferris@east.sun.com> wrote:

>Mark,
>
>Okay, if we take this approach (reuse application semantics)
>to its fullest interpretation, then yes, SOAP Server.* faults
>would be reported using 500 and possibly MustUnderstand.*
>faults (of course, depending upon your perspective, either
>the client is at fault for including a header that the server
>doesn't understand or the server is at fault for not understanding
>the header;-).



> However, IMHO, Client.* faults should be reported using 4xx
>class of HTTP status codes, not 500. They should probebly be closely 
>matched to the various 4xx errors as well.

Exactly.  I've argued for this already;

http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0017.html

>For instance, say I've got a SOAP-RPC service and I receive
>a message that is targetted at a method name I don't recognize.
>That would probably be classified as a 405 or possibly a 400
>depending upon your perspective.

405 is specific to HTTP methods (the returned Allow header is defined to mean that the HTTP request line can be used 
to invoke any of those methods on the resource in question - different than RPC-in-the-body), but it's certainly a client 
error.  So yes, 400 would be best.

>In addition, I would think that there would need to be some
>explicit advice given as to whether an application should
>use the SOAP Fault mechanism to report application-level
>stuff such as "transaction not completed, insufficient funds".

SOAP faults should be for SOAP errors, not app errors.  I agree that the spec could be clearer about this.

>As I believe has been previously stated, this isn't a Fault
>in the same sense as a SEGV. The application successfully processed
>the request, it just doesn't have the outcome that the
>sender might have preferred;-)
>
>The problem with the current draft is that it exclusively
>uses 500 status for all SOAP Faults:
>
>	If an error occurs while processing the request, the 
>	SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" 
>	response and include a SOAP message in the response containing a 
>	SOAP fault (see section 4.4) indicating the SOAP processing error.

I agree.  But at least it's better than 200. 8-)

MB
Received on Thursday, 19 July 2001 10:19:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT