RE: Issue 133: SOAP and Web Architecture: Draft sentences for HTT P bi nding preamble.

FWIW... there was discussion at the recent TAG F2F of the possibility of
defining a new QUERY method for HTTP. The following is an extract from IRC
Log which is publically visible at [1] (PaulC also mentioned this on
last-week's WG call):

22:22:00 [IanTAG-MI] 
TBL: I propose we right this up as a hole in the architecture - the
parameters are ridiculous to represent as an identifier, but it's
nonetheless idempotent. There should be something just like POST but with
QUERY to tell the proxy that there are no side effects. 
22:22:10 [IanTAG-MI] 
PC: Is this a new requirement on HTTP? 
22:22:36 [IanTAG-MI] 
TBL: Yes. The Arch principle is that, if what you are doing has no side
effects, under the visibility of "rest" you should use an HTTP method that
has no side effects. 
22:23:07 [IanTAG-MI] 
...we note that there is a hole in the HTTP spec since for processing of
large quantities of data, there is no suitable method. A logical solution is
to make an HTTP Query method. 
22:24:05 [PaulC] 
And who do we direct this recommendation to? 
22:24:38 [IanTAG-MI] 
TBL: Ask Philipp Hoschka to put on the agenda of the IETF liaison call. 
22:25:37 [IanTAG-MI] 
Action TBL: 

In the long run this would seem like the right approach to me... to define a
new 'idempotent' method for HTTP that has GET with body like semantics.
However, as you see accomplishing that would involve liason with the IETF
and is certainly outside the scope of the current XMLP-WG charter. In the
long run it would give the means to 'efficiently' carry a SOAP envelope in
an HTTP request AND signal that operation is (intended to be) without
side-effect. In effect it would be an HTTP away to carry an idempotency
property outside of the SOAP envelope.

Practically, this will take a while, and there may not be a concensus that a
new QUERY method is better than GET-with body (or some other proposal aimed
at solving a similar problem).

In the meantime, URL encoding of SOAP envelope feels like a horrendous
kludge...

There is separately, the philosopical question of how much of the underlying
protocol you want to make visible to a SOAP user. I think I can live with
the notion that an application might signal that a given exchange of
messages is intended to be without side-effect. How that would then be
expressed in an email or TCP/DIME like binding (perhaps slips into the
envelope somewhere - a header?) remains open.

There is also a possible alternate view... that SOAP is about an exchange of
messages; that the web resources referenced by request URIs represent
message queues; that the POSTING of a SOAP message request that referenced
queue accept the POSTed message as a subordinate of the queue entry; of
course this hides any material effect that the processing of the message by
intermediaries and endpoints, but it is a way to (begin-to) reconcile a
message-oriented SOAP view with a REST oriented view.

Regards

Stuart Williams
[1] http://www.w3.org/2002/02/12-tagmem-irc

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 19 February 2002 20:05
> To: Martin Gudgin
> Cc: Paul Prescod; Williams, Stuart; xml-dist-app@w3.org
> Subject: Re: Issue 133: SOAP and Web Architecture: Draft sentences for
> HTTP bi nding preamble.
> 
> 
> 
> Sure, but that isn't the point; the point is that SOAP 1.2 doesn't
> offer a way to make idempotent requests in a way that is compatible
> with the Web architecture. The WG's HTTP binding is, at best,
> incomplete, *if* "compatibility with the Web architecture" is
> considered a requirement. 
> 
> Such a requirement isn't stated in the Requirements document or the
> Charter. An argument could be made that it's self-evident, since the
> WG is a) in the W3C and b) is chartered to define an HTTP binding.
> 
> 
> 
> On Tue, Feb 19, 2002 at 06:49:54PM -0000, Martin Gudgin wrote:
> > 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/
> > >
> > 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
>

Received on Wednesday, 20 February 2002 08:40:23 UTC