Re: XML Protocol and Axioms of Web Architecture

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