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

Mark Nottingham wrote:
> 
> On Wed, Jul 18, 2001 at 04:50:42PM -0400, Mark Baker wrote:
> > >> As SOAP/HTTP reuses HTTP's application semantics (see the charter
> > >> 8-)
> > >
> > > reference?
> >
> > 2.4, "Out of Scope; Application Semantics"
> 
> That's taking it completely out of context. Section 2.4 is a call to
> avoid the specification of *SOAP* application semantics. How does
> that translate to a requirement to reuse HTTP's application
> semantics?

I didn't say that *SOAP* had to reuse HTTP's application semantics, I
said "SOAP/HTTP" - meaning the binding - should.  Sorry if that wasn't
clear.

Anyhow, how can 2.4 *not* mean to reuse the application semantics of the
application protocol to which it is bound?  If it doesn't define its
own, then where do they come from?

> > I believe the meaning of a SOAP server fault fits within the
> > definition of 500 (and implicitly, the definition of 5xx).
> 
> "Server" is being used in two different contexts (their respective
> documents). An HTTP server is very different from a SOAP server, and
> may be implemented by a completely different process.

I look at it this way; sending a SOAP message over HTTP means
transferring it with HTTP POST  semantics.  So if the transfer of that
message fails, i.e. if the message cannot be processed (or otherwise
"accepted as a subordinate", per 2616 sec 9.5) by the resource
identified by the POST URL, there's an HTTP error to be reported because
the POST did not succeed.  That the reason for it not being accepted was
a problem with a processor that isn't the web server, matters not; the
POST failed, and this has to be communicated.

Henrik, help me out here! 8-)

MB

Received on Wednesday, 18 July 2001 18:56:21 UTC