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

David,

7/18/2001 4:29:07 PM, David Crowley <dcrowley@scitegic.com> wrote:
>SOAP errors are communicated with SOAP Fault.  HTTP errors are communicated 
>with HTTP status codes.

See below.

>I'm struggling to see why a new code or an existing error code should be 
>setn by HTTP because of a SOAP error.  HTTP shouldn't know about 
>SOAP.

Agreed.

>  SOAP shouldn't know about HTTP.

Agreed.

>  HTTP should not have to be extended 
>to handle SOAP.

Agreed.

>  I liken this to adding a new send() or recv() error code 
>because of an application error error.  Doug had the right analogy with the 
>Yahoo example.  Could you imagine if Yahoo (and MS, CNN, CNET, Excite, 
>etc.) added HTTP status codes for every application or user error?

I don't see how that addresses my point.

If SOAP were an application protocol being tunneled over HTTP, then I'd agree completely with you.  But it isn't, it's a 
protocol that extends application protocols.  So when the work is done to bind it to an application protocol, the 
semantics of that application protocol have to be reused.  HTTP has an existing semantic for specifying that an 
unexpected error has occurred that prevents the response from being provided at this time, the 500 response code.  
Therefore SOAP should use this when it has something similar to communicate; the SOAP server fault.

MB

Received on Wednesday, 18 July 2001 17:24:35 UTC