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 11:15:39 -0700
To: Rich Salz <rsalz@zolera.com>
CC: xml-dist-app@w3.org
Message-Id: <20010719151325.VREA11181.tomts14-srv.bellnexxia.net@SPARTICUS>
7/19/2001 5:14:57 AM, Rich Salz <rsalz@zolera.com> wrote:

>> So what's wrong with using the application semantics of the protocol
>
>That is exactly what we should do.

I'm glad to hear that, but it is inconsistent to state that and at the same time suggest a tunneling model.  The only way 
this wouldn't be inconsistent is if POST meant "tunnel this protocol".

>  We just disagree that 500 is a valid
>status code to contain application data.

A SOAP fault is as much "application data" as an HTML document saying "Sorry, unexpected server error, try back 
later" when carried on a 500.  i.e. it's not application data, at least not by any definition of it that I'd use.

>If a SOAP target wants a digitally signed message, and doesn't get it,
>should it return 401, or should it leave that to the HTTP layer in case
>the POST requires a basic auth?

If the POST requires HTTP authentication to be performed, and it fails, a 401 should be returned.  As for the signature, 
if it's not received, the server should return a SOAP client fault (hopefully on a 400 HTTP response per my suggestion).

>If doing SOAP over email, a fault can only be returned by sending a
>reply message, not by responding with a 451 status and using
>continuation lines.  Right?

Sorry, I'm not that familiar with email.

>Once you start to "tightly integrate" SOAP messaging semantics with the
>underlying transport, all sorts of nasty corner cases come up, like the
>two I just mentioned.  That's why it's much simpler and much more clear
>to think of it as tunneling.

It is without a doubt clearer, because you've bumped yourself down a notch in the stack; you're no longer working with 
an application protocol, you're working with a transport protocol, and it's a lot easier to understand send() and recv() 
than it is GET, POST, and PUT.  But by tunneling, you've forced yourself to start reinventing application semantics on 
top of the tunnel, which is in turn on top of an application protocol.

I'll ask this again, because it's an important question; if we're doing tunnelling, where are the application semantics 
defined?

MB
Received on Thursday, 19 July 2001 11:13:55 GMT

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