W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Re: Issue 133, and permitting no body

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 1 Feb 2002 07:14:33 -0800
To: Yves Lafon <ylafon@w3.org>
Cc: Mark Baker <distobj@acm.org>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org
Message-ID: <20020201071432.D1168@mnot.net>

I like this! I can see four possibilities (not mutually exclusive);

1) GET w/ SOAP envelope serialised in URI, response carries envelope
2) GET w/o any SOAP envelope, response carries envelope
3) POST w/ SOAP envelope, 303 See Other, #2
4) GET w/ body

1 is interesting but tricky to get the serialisation right (both in
terms of length and a canonical encoding). Remember that the *entire*
envelope becomes the cache key, which isn't very useful...

My concern with disallowing the SOAP body is that people will
inevitably just stick something body-like in a header.

Mark seems to be aware of my misgivings about GET-with-body. :)

Also, remember that SOAP headers can be mapped to protocol-specific
features; there's nothing stopping Bob from taking his nifty
transactional SOAP header and describing how to serialise it as a
HTTP header.

So, my money is on #2&3. I'd also note that the entail the least
amount of work for the WG.

On Fri, Feb 01, 2002 at 01:30:36PM +0100, Yves Lafon wrote:
> On Thu, 31 Jan 2002, Mark Baker wrote:
> > Noah, this is one of those "web architecture" issues again.
> >
> > Encoding a SOAP envelope in a URI is using GET to tunnel that envelope,
> > and isn't respecting GET semantics (which are "give me a representation
> > of the resource identified by the Request-URI").
> Well, having the envelope sent as a parameter is OK.
> Another way to look at the GET method would be to have inbound one-way
> messaging, but you need to have a way to identify that you will get
> something without a body.
> An example would be to do a POST to register a listener to a resource, you
> want to listen to the weather in "foo" city
> POST /register
> <blah>
> HTTP/1.1 303 OK
> Location: http://www.example.com/weather/foocountry/foocity
> And then you get "events" (ie, weather information) using GET method. Of
> course it can be cached and ETag or Date revalidation can be used to
> detect any new "event".
> It is clear in this case that those GETs are idempotent methods.
> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."

Mark Nottingham
Received on Friday, 1 February 2002 12:02:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC