Re: Issue #12: HTTP Status Codes 500 v 200

Hi Michael,

mrossi@csc.com wrote:
> 
> Mark, your arguments highlight the fundamental decision that needs to be
> made: is XMLP/SOAP a protocol in it's own right (layered on top of HTTP) or
> is it an extension of HTTP? However, even in your discussion I don't think
> this is clear.

Hmm, I thought I was quite clear when I said "It is *not* a layer above
HTTP in the same way
that WebDAV isn't a layer on top of HTTP".

> You illustrate how HTTP status codes _can_be_ extended (or
> used) to accomodate an XMLP/SOAP processor, but the very fact that you're
> able to correlate the SOAP faults with HTTP status codes says to me that
> SOAP was clearly designed as a separate protocol.

I don't see how that follows.  Just the opposite in fact ... assuming by
"separate protocol" you mean "separate layer".  I *would* call SOAP
(WebDAV too) a protocol because it introduces semantics that change the
interface/contract between parties at each end of the connection (in
SOAP's case, mustUnderstand).

The reality here is that SOAP is many things.  When used with an
application protocol, it is an extension.  When used with a transport
protocol, it can be used as one would use BXXP (framing, building
application semantics on top).  Or it can be used for RPC.  This
discussion is about using it with application protocols, specifically
HTTP, so my comments relate only to this use of it (except where
otherwise stated).

> FWIW, I'd prefer that they be layered protocols. This would provide true
> independence from HTTP and the ability to map XMLP to other
> transfer/transport protocols more cleanly.

Independance can also be achieved as an extension for simple semantic
extensions such as SOAP's mustUnderstand, which is a very generic notion
reusable across many other transfer protocols.

> As for the 'pre-existing
> applications' argument, I'd suggest that they treat the HTTP status codes
> more carefully. If these applications are assuming some target application
> state based on the HTTP status they're just wrong. Also, on the scenario
> questions I believe the guideline is that if the request message could not
> be delivered for some reason (any reason - like an invalid URL or failure
> to start the target app.) than HTTP should return a failure status. If the
> message was delivered but a higher-level protocol error ocurred, then HTTP
> should return a success status (because it was successful in its mission)
> and the higher-level protocol should handle its own error.
> 
> BTW - can anyone tell me the difference between a transfer protocol and a
> transport protocol? And for what practical purpose would anyone need to
> make such a distinction? If at all possible, please don't unnecessarily
> overcomplicate life any more than has already been done. Thanks.

A transfer protocol has application semantics.  A transport protocol
doesn't.  In other words, a packet is *transported* for the purpose of
getting it to the other side, whereas a document is *transferred* for
the purpose specified by the developer (where the set of possible
purposes is defined by the protocol).  e.g. HTTP PUT means something
very different than POST, but both are represented as a document being
transferred from sender to receiver.

MB (btw, I'm only representing myself here - I'm on leave from Sun)

Received on Monday, 4 June 2001 14:19:31 UTC