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

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 14:15:15 UTC