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

Sure, an implementation that used the PUT method to call a
server that only supported the POST method or vice-versa could never
interoperate. The OPTIONS method allows for an entity body as well.
What does this mean if anything?

A server that required certain proprietary extension entity
headers (because nothing says that they shouldn't) to effect
services above what is natively provided by HTTP instead
of using the SOAP extension mechanisms (actor/mU) won't
be accessible to a SOAP client that doesn't know about them.

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.

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? Or, should they merely echo
back the contents of the request?

Cheers,

Chris

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)

Received on Wednesday, 18 July 2001 15:02:45 UTC