another approach to status codes, etc. in HTTP binding

> 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)

Received on Wednesday, 18 July 2001 13:12:46 UTC