Re: Seeking clarification about the use of the HTTP binding

Hugo Haas asks:

> If the HTTP binding is used with the SOAP
> Request-Response MEP, can the response _not_ be
> sent in the HTTP response message body, e.g.
> because the SOAP request was using an addressing
> extension to redirect the SOAP response?

Speaking just for myself, I think we have to distinguish the following two 
cases:

1) There is no header in the message to signal the change in response 
handling

In this case, I think the Recommendation is clear.  Features, including 
implementations of MEPs by bindings, can be introduced either by 
processing an understood header or by the specification of the transport 
binding.  In this case, neither applies in my opinion.  The HTTP binding 
says that the HTTP response Entity body contains [1]: "SOAP message serialized according to the rules for carrying SOAP messages 
in the media type given by the Content-Type header field.".  I agree that this should have been clearer in verifying that the SOAP 
message in question is the only one it could coherently be per the 
Request/Response MEP, I.e. the SOAP-level response. 

2) There is a header in the message to signal the change.  The header is 
understood and processed by the ultimate receiver.

This case is a little more subtle.  My reading is that an understood 
header can change almost anything in SOAP's rules, providing the 
specification for a header says it does.  Doesn't make it a good idea, but 
technically legal I think.  So, from that point of view you could 
implement a request header signalling the change in response mapping that 
you propose.  However, I think it's important to realize that in this case 
you are more or less overtly changing the interoperability contract 
established for the HTTP binding described in option 1.  You are in that 
sense using a header to say that you are not in fact using that base 
binding as specified.  Indeed, if for some reason the requesting node was 
unaware of the trickery, it would indeed be confused by the lack of a 
proper SOAP response. 

Certainly SOAP intermediaries might be confused as well  So, any header 
should probably be explicitly addressed to "next", probably 
mustUnderstand, and have a specification that requires re-insertion at 
each node.  That forces each intermediary to be aware of what you're 
doing.  Otherwise, you run the risk that intermediaries would (correctly) 
expect the SOAP response in the HTTP response (though I admit that use of 
intermediaries with HTTP is murky at this point for other reasons.

Furthermore, if you did try to use such a header, I would strongly urge 
you to write it's spec as an alteration to the HTTP binding spec, 
indicating how the semantics of the Request/Response MEP are mapped to 
your new transport conventions.  In other words:  who gets to generate 
SOAP faults, how are they reflected back to the sender, etc.  You should 
also talk about the intended implementation of intermediaries. 

Another consideration.  If you do send back both an initial SOAP response 
in the HTTP Response, and then another, that's clearly a new MEP.  You'd 
have to write a specification for that MEP, and an update to the SOAP HTTP 
binding indicating that use of the new MEP was enabled when the understood 
header was present.   MEP's have a very strict role, which is primarily to 
set down the pattern in which >SOAP< messages are exchanged.  If you still 
have one outbound, and one inbound, with addressing of the response 
implicit in the path taken by the request, then that might well be the 
Request/Response MEP in the SOAP Recommendation.  If not, it's a new MEP 
and you must write a specification for that and indicate which bindings 
support it.

Finally, I think there's a case to be made that this is a significant 
misuse of HTTP itself, which has a pretty strong notion of 
request/response on a POST (you couldn't send the header on a GET.)  I 
think the burden would be on you to write the specification for the header 
in a manner that used HTTP appropriately (or else, I suppose, to admit 
that you are intentionally misusing it.)

Bottom line:  I think it's forbidden without a header and at best a very 
suspect design decision even with a header.  Still, I suspect that you 
could with care write the spec for a header that would be technically 
legal, especially if the only SOAP message going back was indeed the final 
response.  The above is just my opinion.  Other readers of the scrolls my 
come to a different interpretation.

Noah

[1] http://www.w3.org/TR/soap12-part2/#http-respbindprocess

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








Hugo Haas <hugo@w3.org>
Sent by: xml-dist-app-request@w3.org
11/12/2004 12:18 PM

 
        To:     xml-dist-app@w3.org
        cc:     www-ws-desc@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Seeking clarification about the use of the HTTP binding


Hi.

I am writing on behalf of the WS Description WG.

While discussing MEPs, we could not come to an agreement about a
particular use of the SOAP 1.2 HTTP binding. We would therefore like
clarification about the following.

If the HTTP binding is used with the SOAP Request-Response MEP, can
the response _not_ be sent in the HTTP response message body, e.g.
because the SOAP request was using an addressing extension to redirect
the SOAP response?

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/