"A priori" and the default HTTP binding

I've identified an issue with the default HTTP binding, regarding
how it satisifies R505[1], the requirement that no additional a priori
agreement be established.

The closing text for issue 54[2], which I provided, is correct that
HTTP has some of the necessary features by which uncoordinated parties
can coordinate SOAP support.  The problem is that the current HTTP
binding doesn't use them.

As an example, I can write an HTTP conformant app which accepts any HTTP
POST content and "saves" that content to a local file.  If somebody
POSTed a SOAP envelope to this app, they would have the expectation
that, at the very least, the processing model would kick in to the point
of faulting on unrecognized mustUnderstands.  Yet this isn't the case
with my app, because it knows nothing of SOAP.  This shows that having a
HTTP URI and a SOAP processor conforming to our default binding isn't
sufficient to satisfy R505.

FWIW, SOAP 1.1 addressed this issue with the RFC 2774 binding, which it
used to assert that the SOAPAction HTTP header must be understood.  I
personally believe that this is the cleanest way of solving this
problem, though I expect that the WG does not concur.

So, one non-2774 way of addressing this issue would be to state that as
part of the binding, in order for a SOAP client to know if it's dealing
with a SOAP processor, it has to negotiate that support.  An example
could be;

HEAD http://example.org/some-soap-processor HTTP/1.1

response;

SupportsSOAP: true
or
SupportsSOAP: http://www.w3.org/2001/12/soap-envelope

or something like that.

To avoid requiring a separate round trip before every POST, we could
require that this header be used on the POST response to indicate that
the resource supports SOAP; anything not returning the header on a 2xx
response would be considered an app similar to my example app above
(i.e. not SOAP).

 [1] http://www.w3.org/TR/xmlp-reqs/#z505
 [2] http://www.w3.org/2000/xp/Group/xmlp-issues#x54

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 15 April 2002 14:33:00 UTC