RE: SOAP spec.: HTTP binding

>>major reason for doing it the way SOAP specifies is to not break HTTP

Everything in [1] supports my point of view. Using 200 return codes does 
not break HTTP, it in fact supports the issues stated in [1].  The primary 
"reason" stated in [1] is for using 500 (*At most* - is the language used) 
is so that proxy/caching servers don't cache errors.  However, it would be 
a mistake for a proxy/caching server to cache a SOAP request/response in 
the first place.  In the same respect as it would be to cache a SOAP error.

>> At most, the "generic" HTTP codes 200 (for complete success) and 500 
>>(for complete failure) 

Further, this [1] is a real problem too:
>     ... and it must be able to operate even
>     if the message-body of an error (500) response is not transmitted
>     back to the client intact.

If the proxy/caching server appends/changes the XML SOAP response 
if it is 500, this seems to be a real problem with the protocol.
Unless the proxy/caching server understands SOAP, which is what
we are trying to avoid in the first place.



-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
Sent: Monday, December 18, 2000 2:57 PM
To: Kevin Koch; xml-dist-app@w3.org
Subject: RE: SOAP spec.: HTTP binding


Hi Kevin,

Before starting another major thread on this subject, you might want to
have a look at [1]. Believe me, this has been discussed a lot but the
major reason for doing it the way SOAP specifies is to not break HTTP.

Btw, some people on this list responded [2] to [1] - you might want to
read this too.

[1] http://www.normos.org/ietf/draft/draft-moore-using-http-01.txt
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0178.html

Henrik

> This doesn't seem right.  It also causes problems for people 
> wishing to 
> write simple soap clients.  Many HTTP APIs handle HTTP errors very
> differently
> than standard returns.  Depending upon the API, it is not 
> always possible to
> 
> read the body of an error response.  Further, in my opinion, 
> HTTP errors
> should be reserved for actual HTTP server errors, not SOAP 
> request errors.
> This type of functional overloading, although well intentioned, is not
> appropriate.

Received on Monday, 18 December 2000 17:54:19 UTC