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

Dan,

Dan Gunter wrote:
>  From what I understand, SOAP is _not_ an extension of HTTP, instead
> it is a protocol with an HTTP binding. I really hope that other
> bindings remain possible.

It is both.  The binding is an *extension* binding, not a layered
binding.  More below.

If it were not for mustUnderstand, actor, and SOAP versioning (with
which to reason about compatibility changes with the previous two
features), SOAP would simply be a XML based syntactical framework for
extending HTTP (and other application protocols).  What would normally
be done with a new HTTP header could be done with a SOAP header.

mustUnderstand, actor, and SOAP versioning are what make SOAP a protocol
and not *just* a new extension syntax (obviously it's also that).  They
are also generic features that apply to other application protocols
(specifically transfer protocols).

In order for protocol A to be a layer on top of protocol B, the
interface to developers (i.e. a library) should expose only protocol A
semantics.  With using SOAP over HTTP, you as a developer are using HTTP
semantics (specifically POST).  They are exposed to you.  Contrast this
with HTTP over TCP - do you as an HTTP developer know or care when an IP
packet arrives out of order?  You don't, because HTTP *is* a layer on
top of TCP.  SOAP is not a layer on top of HTTP.

> Pushing SOAP status information up into HTTP seems to me like a hack
> that's going to cause no end of headaches for other bindings (what
> happens when an intermediary needs to translate from HTTP<->UDP? does
> it have to parse all the messages going back HTTP-side so it can stick
> in the right error code? ugh..). Also, it complicates the spec.

HTTP<->UDP?  I'm not sure what that means.  Those are different layers
in the stack.

> I like the XML-RPC take on the issue: "Unless there's a lower-level
> error, always return 200 OK.".

It's simple, for sure.  But it doesn't let existing web applications or
intermediaries know what's going on, and that's a bad thing.  Luckily,
it is a requirement of the XML Protocol working group that XMLP not
interfere with the proper operation of "transport" (meaning "transfer")
intermediaries;

  http://www.w3.org/TR/2000/WD-xp-reqs-20001219/#N1137

MB

Received on Friday, 8 June 2001 11:28:03 UTC