Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP bi nding preamble.

Seems to me that nothing in our spec precludes someone from defining a GET
based binding. I don't think our HTTP binding is such a beast. I don't see
the GET binding as being in the 'minimum required to declare victory' space.

Gudge

----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: "Martin Gudgin" <marting@develop.com>
Cc: "Paul Prescod" <paulp@ActiveState.com>; "Williams, Stuart"
<skw@hplb.hpl.hp.com>; <xml-dist-app@w3.org>
Sent: Tuesday, February 19, 2002 5:42 PM
Subject: Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP
bi nding preamble.


>
> Hi Gudge,
>
> On Tue, Feb 19, 2002 at 12:22:35PM -0000, Martin Gudgin wrote:
> >
> > It is unclear ( to me at least ) how such a call would differ from
> > a standard HTTP GET. What would make it SOAP? Just the fact that
> > the HTTP response would contain an Envelope element? Or the fact
> > that the Content-Type header of that response would be
> > application/xml+soap? Or both?
>
> Speaking only for myself (there seem to be a number of positions on
> this issue!), this (both) is what I'd like to see.
>
> Why bother? Because if it's not specified, it won't be widely
> implemented. The 'profiles' (not my term) of SOAP use that get
> defined early are important. It gives you compatibility with the Web
> architecture, low-level caching, etc. and is easy to do.
>
>
> > Also, given that the Envelope will *NOT* be used to serialize the
> > request is it really SOAP, given that the Envelope is a core part
> > of the spec? Given that the envelope is hierarchical ( it is an
> > Infoset, after all ) I'm not sure I can see a reasonable way to
> > encode it into the query string ( although I can see how you might
> > encode very simple requests into the URI ).
>
> I'm not too concerned with 'what is SOAP/is it SOAP' arguments,
> because SOAP is a pretty slippery concept (is it a messaging
> framework? an RPC protocol? A substrate of HTTP? a layer? ... ).
>
>
> > Also, it would seem *VERY* problematic to try and use SOAP Headers
> > in such an example, where are we supposed to put those in a GET? I
> > understand that idempotent HTTP requests should use GET. But it
> > seems that some of the things I might want to include in an
> > idempotent SOAP request might include SOAP headers. Are you
> > suggesting we define a way to encode SOAP headers as HTTP headers?
>
> I'd say no; in the request, they can use features of the underlying
> protocol, but there is no slot for an envelope (or maybe just
> headers; see below). Yes, this is a constraint on the use of the
> binding, but it's useful, and I don't think it breaks SOAP to define
> it.
>
>
> > Or maybe the query string should just be ?xml='<soap:Envelope....'
> > in which case perhaps all these problems go away... Is that what
> > you think we should do?
>
> No! There should be an effort to specify how to express section
> 5-encoded data into a query string; it may even attempt to defined a
> framework for expressing SOAP headers as HTTP headers (although I'm
> a bit doubtful about this one).
>
> You end up with something with following properties:
>   - uses GET
>   - request only allows bodies with section 5 encoding
>     (which are serialised in the query string)
>   - all HTTP protocol features are available
>   - no SOAP headers are possible in the request (but see above)
>   - response is a normal HTTP/SOAP response
>
> I don't know if this is a new binding or a binding feature of the
> HTTP binding; perhaps it's a feature, since it limits the
> functionality of the envelope.
>
> (I'd put my hand up to do a proposal for this, but I can't prioritise
> it right now; if there's support for the idea, though, I'll see what
> I can do.)
>
> Cheers,
>
> --
> Mark Nottingham
> http://www.mnot.net/
>

Received on Tuesday, 19 February 2002 13:50:25 UTC