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

The way I'm thinking presently is that a we provide that a SOAPFault
MAY be carried on an HTTP 500, but this is NOT a requirement
as is currently specified in 1.1 and 1.2WD. 

We could add language to the spec that recommends that HTTP 500 
status responses SHOULD be reserved for use by the SOAP processing 
(as opposed to the SOAP *application* processing) aspect of a server 
and that application-level SOAPFault messages be responses with a 2xx
status code.

My $0.02,

Cheers,

Chris

Jacek Kopecky wrote:
> 
>  Hello all. 8-)
>  I apologize if I repeat somebody but I didn't read the whole
> bulk of the discussion this time.
>  My view on 2xx/4xx/5xx is the following:
>  We've heard that SOAP is either an extension of HTTP or a layer
> above HTTP.
>  We've heard that HTTP is an application protocol, not a
> transport protocol.
>  Every application protocol can be "abused" to serve as a
> transport protocol.
>  Now we have XMLP. I'll use this acronym because I think we
> should consider what we would do if we built XMLP from scratch,
> and then compare it with what SOAP does and decide on the
> relative merits. What I say about XMLP may not be true about SOAP
> Version 1.2, I'm changing the facts here for the sake of
> discussion.
>  XMLP messages are defined in terms of Infoset, with processing
> rules based on the Abstract Model. We need to transport the
> messages from one XMLP node to another. We are in need of a
> transport protocol. TCP will suffice for some applications.
>  I guess nobody will argue that TCP is an application protocol.
>  Now we see HTTP, and we know HTTP is good. And we know HTTP
> traverses firewalls. And we decide to use HTTP.
>  We use HTTP as a transport protocol because we need nothing more
> from it than from TCP. This is a layered approach so XMLP faults
> are HTTP successes.
>  I can't see any reason why anybody would want to switch from 2xx
> to 4xx/5xx in the scenario described above (_after_ having TCP
> transport).
>  Now back to reality - we have SOAP/1.1 and a working draft of
> SOAP Version 1.2 and we started with the HTTP binding modeled as
> an extension of HTTP. We are considering binding to TCP now.
>  I can see how one binding could be layered over one protocol
> while an other binding would extend an other protocol, even though
> it is a bit of inconsistency.
>  Anyway, does modeling the HTTP binding as an extension of HTTP
> bring some significant added value? Will then the TCP binding
> actually create a whole 'nother application protocol?
>  So to conclude - I'm advocating the layered approach - use 2xx
> for faults, and all that.
>  Best regards,
> 
>                             Jacek Kopecky
> 
>                             Idoox
>                             http://www.idoox.com/
> 
> On Wed, 18 Jul 2001, Mark Nottingham wrote:
> 
>  >
>  > > In other words, I think we should allow SOAP applications to use HTTP
>  > > with all the bells and whistles that HTTP provides including using all
>  > > status codes and header fields. In other words, let HTTP be HTTP :)
>  >
>  > What I'm hearing, then, is that the HTTP binding (and bindings in
>  > general) should be expansive; e.g.,
>  >
>  > * SOAP envelopes can be encapsulated in request messages which have a
>  >   method which permits an entity body (i.e., POST, PUT)
>  >
>  > * SOAP envelopes can be encapsulated in response messsages which have
>  >   a status code which permits an entity body (i.e., 200, 400, 500,
>  >   etc.)
>  >
>  > Thinking aloud, I'd be happy to take this approach *from a
>  > theoretical standpoint* (more about that later) if we specify that
>  > transport-related underlying protocol mechanisms (e.g., method,
>  > status code, etc.) have no effect on how the SOAP message is
>  > processed; i.e, their semantics are used to get the HTTP message (in
>  > this case) around, not to hint or affect SOAP processing.
>  >
>  > This is because if there were a relationship between protocol
>  > mechanisms and message processing, there would need to be a mapping
>  > between them, and this could get ugly quickly.
>  >
>  > The upshot of this is that the HTTP binding wouldn't specify ANY
>  > methods or status codes to use (except for the constraints as above),
>  > but merely reference the specification.  The onus is on
>  > implementations to assure that they can handle any messages sent
>  > their way by a particular binding.
>  >
>  > This is a fairly radical change to specifying particular status
>  > codes for particular SOAP messages, but I'm warming to it.
>  >
>  > Thoughts?
>  >
>  >
>  >

Received on Thursday, 19 July 2001 14:08:01 UTC