- From: Hugo Haas <hugo@w3.org>
- Date: Tue, 21 Aug 2001 17:34:11 -0400
- To: Mark Baker <distobj@acm.org>
- Cc: Aaron Swartz <aswartz@upclink.com>, www-archive@w3.org, Dan Connolly <connolly@w3.org>, Yves Lafon <ylafon@w3.org>, "Eric Prud'hommeaux" <eric@w3.org>
Hi Mark, thanks for the quick answer. * Mark Baker <distobj@acm.org> [2001-08-20 21:01-0400] > > However, there is a gain in using a SOAP request (in an HTTP POST > > request, as currently stands) instead of a simple GET: you get a > > processing model, including the fact that you can use intermediaries; > > e.g. a third party (key escrow) could authenticate my request in some > > way and add some information along with my request and send it to the > > final recipient afterwards. > > You also get this with HTTP. It has a processing model. SOAP/HTTP > just extends it in some useful ways. Agreed. > > The problem with this is that such an HTTP binding forbids HTTP > > intermediary caching. > > Just to be clear, because it may not be from the context of this > statement; this is only a problem if you're not obeying POST > semantics. If you are, then no caching is expected. Agreed, this is a good point. [..] > > HTTP GET requests do not have an entity body. POST requests do. > > Nevertheless, you could encode your SOAP request in some way in your > > GET request, by using, say a 20k-long URI; [6] suggests however that > > current HTTP implementations will not really like that. > > This is my biggest issue with SOAP. Defining headers in XML is fine > and dandy, but many of those headers will be useful over GET as well. > How do we represent those without a body? [..] > > In the end, I wonder if this "tunnelling" of SOAP in HTTP is really > > worse than using GET requests (see also Mark's proposal of two > > bindings[9]). > > Without a doubt, yes, it's worse. > > > I think that the advent of SOAP makes use of the Web in > > a new way, which might be fine as long as 1) we are aware of it 2) > > this is the way to go 3) we clearly document it. > > And 4) make sure it's identifiable on the network so that we can > route/manage/filter it. This is why I was advocating for a separate media-type for SOAP content (so were you in [10] actually). > > [ I will stop here for tonight, because I don't think that I will > > solve the problem tonight... ] > > > > I am proposing (in a separate email, sent to xml-dist-app) to open two > > issues refering to this email: > > > > 1/ The HTTP binding of the SOAP Version 1.2 specification[5] does > > preclude caching of information at the HTTP level in case of > > requests having the semantics of an HTTP GET request. > > I'm not sure of the value of bringing that up. I expect the response > you'd get from the tunneling people would be "ok, so what?". 8-) > > In the end, we're not going to stop people who want to tunnel from > tunneling. All we can do, as mentioned, is identify it. That's what > my two-binding approach proposed (and Henrik's proposal did the > same two, in an unbounded # of bindings kinda way). > > > 2/ SOAP Version 1.2 over HTTP[5], in its current form, misuses the Web > > architecture. There is a risk of abuse of the HTTP POST method over > > a single URI (e.g. > > <http://example.com/IWillDoAnyProcessingYouNeed>). > > I disagree with that statement, because there exists at least one use > of SOAP that *doesn't* abuse the architecture of the Web. But for RPC > and for other tunnel uses of HTTP, it is true. I don't think that RPC is always harmful. Only RPC requests which don't carry the semantics of HTTP POST requests (e.g. getStockQuote) can be considered harmful. > I believe that the best we can do here is; > > - make sure that there exists a canonical and authoritative means > of identifying a tunnelled use of HTTP > - document that this use of HTTP abuses the architecture of the Web Let me tweak the formulation of the issue (merged both issues into one) then: The current HTTP binding of SOAP can be seen as "tunelling" SOAP messages in HTTP POST requests. When the SOAP message transferred does not follow the semantics of HTTP POST requests[11], that kind of HTTP request does not respect the Web architecture[12]. This should be documented, and such traffic should be identifyable. Moreover, the correct use of HTTP should be encouraged: use of HTTP GET for operations on resources not having side-effects, use of reasonable HTTP return codes when SOAP messages are carried in HTTP POST requests, etc. To find out more about this issue, please see the thread started by Aaron Swartz on www-archive[13]. 10. http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0182.html 11. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 12. http://www.w3.org/DesignIssues/Axioms.html#state 13. http://lists.w3.org/Archives/Public/www-archive/2001Aug/thread.html#25 -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
Received on Tuesday, 21 August 2001 17:34:20 UTC