Re: 2xx/202 and "a priori"

Mark Baker writes:

>> I wonder how many SOAP developers are under the impression that if
>> they send a SOAP message to an arbitrary URI, and get a 200 response
>> back, that this means that the SOAP message was processed?  More than
>> a few, I would expect.  Noah's GET-in-SOAP pseudo-proposal[1] appears
>> to work this way.

Let's separate my GET proposal from the existing HTTP Binding.  The 
existing binding mandates that a 200 response to the Post be accompanied 
by a proper SOAP envelope.  The two come together.   That means one of 
three things, I think (a) the SOAP message was processed, producing the 
envelope that's been received (b) the implementation at the other end 
intends to be a SOAP implementation but is buggy...it has produced what 
appears to be a SOAP envelope without actually doing conforming processing 
or (c) through some fluke, an HTTP responder which never intended to be a 
SOAP node miraculously produced a legal response envelope when confronted 
with the POST.  Frankly, I find (c) not worth worrying about at all, and 
(b) only slightly more interesting.  I think if I were worried about (b) I 
would use application-level checking, as for any other buggy HTTP server 
response.

The case (c) that I suggested as implausible with post is indeed quite 
plausible with a GET binding such as mine.  Two scenarios become nearly 
indistinguishable (1) a SOAP node does a GET to what it expects is a SOAP 
node.  It expects that SOAP node to do SOAP-level application processing, 
and respond with a SOAP envelope (2) a SOAP node does a GET with no 
expectation that there is a SOAP node at the other end.   It expects 
Apache, IIS or some such to just send back documents that happen to be of 
the SOAP MIME type.  As things stand, the differences on the traffic on 
the wire is essentially the same for the two cases!  The differences may 
sometimes be observed if SOAPAction is used, as that would sure signal a 
SOAP node as the sender.

It was  exactly this realization that led me to suggest that we add a 
SoapVersion HTTP header, to be used whether or not SOAPAction is used. 
This would allow a receiver to reliably determine whether traffic 
originated at (what claimed to be) a SOAP node or an "ordinary" http 
server.  Because the wire formats are otherwise compatible, it's 
intentional that SOAP nodes can interop with non-SOAP nodes, >>>but I 
believe we need a different MEP for that<<.  Our current MEP, which my GET 
proposal uses, is clear that there are SOAP nodes at both ends, with SOAP 
messages going both ways.  I believe the appropriate MEP for an "ordinary" 
get would be:

        1) A non-SOAP get request sent in binding-specific manner
        2) A SOAP response.

In other words, there is only one SOAP message in this pattern, 
originating from the responder.  The differences can be observed if you 
consider gateway scenarios with intermediaries.  My GET request is subject 
to SOAP intermediary rules and can be relayed.  For a request modeled as 
binding-specific this cannot the done in  a standard manner.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Wednesday, 8 May 2002 12:19:33 UTC