Re: Issue 133, and permitting no body

> I was just seeing in Mark(B)'s description of bodyless SOAP message in a GET
> request the notion that *HTTP* intermediaries could treat the SOAP headers
> contained therein a bit like more finely targetted HTTP headers.

Sorry, I didn't respond to this before because I didn't think it as
important as addressing the other points.  But no, I don't believe
that HTTP intermediaries would need to know about the SOAP headers.
What I intended to say was that SOAP intermediaries that send and/or
receive SOAP messages over HTTP are also HTTP intermediaries.  For
example, they have to strip off the Connection header, etc..

> However, at
> least as I see it, the HTTP intermediaries really have to be SOAP
> intermediaries too. So... if you were wanting to reference
> http://example.org/foo/bar/ what request URI would you use in your HTTP GET
> request, and to what would the HTTP client initially connect?
> 
> <env:Envelope>
>   <env:Header>
>     <ex:reverseProxyControl 
>      env:actor="http://revProxy.example.org/exampleReverseProxy" 
>      env:MustUnderstand='1'>
> 
>      <!- some proxy control incantations -->
> 
>     </ex:reverseProxyControl>
>   </env:Header>
> </env:Envelope>
> 
> Maybe you'll see why the picture feels like its wriggling around abit. Where
> I think it probably takes you is a RESTful SOAP (ie. the latter).

That's a good example, because it demonstrates a problem with using the
GET method; HTTP intermediaries that aren't SOAP intermediaries don't
know about SOAP's extended end-to-end model, and unlike POST (with
Content-Type), GET doesn't provide a means to dispatch to alternate
processors for possible extended interpretation.

That's why we would probably require a GET-SOAP method, which would be
guaranteed to act like GET except in where mustUnderstand is used.

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

Received on Tuesday, 5 February 2002 11:13:13 UTC