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

On Wed, Jul 18, 2001 at 03:02:43PM -0400, christopher ferris wrote:
> Sure, an implementation that used the PUT method to call a
> server that only supported the POST method or vice-versa could never
> interoperate. 

One of the requirements stated was that implementations must accept
messages independent of the HTTP semantics that deliver them.


> The OPTIONS method allows for an entity body as well.
> What does this mean if anything?

OPTIONS bodies have a reserved semantic but no defined syntax in the
HTTP. 

In an expansive model, OPTIONS would be allowed to contain SOAP
messages, but not required. In a tighter model, OPTIONS would be
ruled out in our HTTP binding (for example), but could be
accommodated through another binding. This gets us into a situation
where we identify characteristics of a service through a binding
name, rather than through separate controls for each aspect (in WSDL,
for example). I haven't formed any firm opinions on this yet, but I'm
wary of creating a situation with a plethora of binding definitions,
one for each permutation.


> A client that is written such that it expected a response
> to be correlated with the request would be quite perplexed
> with a server that returned uncorrelated messages in the
> response.

As discussed, there needs to be some agreement about the correlation
mechanism. 


> How should TRACE be handled? (in fact, this hasn't been
> dealt with as yet in any context I've seen). Should processing
> intermediaries treat a TRACE as they would a POST and process
> their content before forwarding? 

Yes. Although a SOAP intermediary might be interposed upon a HTTP
intermediary, that doesn't mean that TRACE semantics are conflated.
TRACE is a directive targetted at the HTTP intermediary; the SOAP
processing model is targetted at the SOAP intermediary.


Just to be clear, I'm equally for:

* allowing SOAP envelopes only in POST requests and 200 responses, or
* allowing SOAP envelopes in any HTTP message with a body, but
  disallowing the conflation of HTTP status code and method semantics
  with SOAP message semantics.

What I want to avoid is the conflation of semantics; either path
accomplishes this. They have very different characteristics, as we
discuss above.



> Mark Nottingham wrote:
> > 
> > Can you give an example?
> > 
> > On Wed, Jul 18, 2001 at 01:51:33PM -0400, christopher ferris wrote:
> > > -1
> > >
> > > IMHO, this "loose" specification approach will lead to all manner of
> > > interop problems.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > A loose specification leads to even looser interpretation
> > > 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?
> > > >
> > > > --
> > > > Mark Nottingham, Research Scientist
> > > > Akamai Technologies (San Mateo, CA USA)
> > >
> > 
> > --
> > Mark Nottingham, Research Scientist
> > Akamai Technologies (San Mateo, CA USA)
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 18 July 2001 15:28:49 UTC