Re: Issue 133, and permitting no body

> 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

Hmm. #2 uses an envelope on a response that presumably isn't a fault.
AFAIK, we haven't defined any meaning for this.

#3 is ok, but doesn't address issue 133 and the use of GET for
side-effect free operations.

> 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...

Right.  It's not useful *because* the body doesn't identify anything
in the vast majority of cases.

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

That's possible, but HTTP GET seems to be mostly immune from this.
I'm not sure if it would be if GET specifically supported a body.

> 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.

I suppose, but it would be really nice to be able to do that

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

Just to reiterate, I'm not suggesting we go ahead and build a GET
binding right now.  My suggestion to allow no body in an envelope was in
case we wanted to define a GET binding this way at some later date.

As I said earlier, we could just address issue 133 with an explanation
of how we only bind to POST, and how the binding respects POST semantics
by making proper use of HTTP response codes.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Friday, 1 February 2002 15:15:56 UTC