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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 20 Feb 2002 13:14:13 -0800
To: Paul Prescod <paul@prescod.net>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org, Martin Gudgin <marting@develop.com>, Paul Prescod <paulp@activestate.com>
Message-ID: <20020220131412.C2544@mnot.net>
On Wed, Feb 20, 2002 at 10:16:59AM -0800, Paul Prescod wrote:
> I both believe and pray that this will not happen. Anyhow, this brief
> dialog is enough to get people thinking about it but I will not believe
> that it will really happy until I hear HTTP wonks like Roy Fielding, Jim
> Whitehead and Mark Baker sign off. I don't believe they will. 
> Nevertheless, it is irrelevant unless the SOAP HTTP binding allows
> people sending messages to choose their HTTP method which I do not
> believe it does today.
> http://www.prescod.net/http/query_alternatives.html

From that document (er, resource):

  There are three partial solutions to these problem. The first is
  merely to use a POST. A POST result may state that the entity is
  cacheable. So if cacheing is the main worry then the problem is
  already solved although this is obviously somewhat of an abuse of
  POST because it violates the "only-GET axiom." Nevertheless, how is
  it better to invent a new method that always violates the axiom
  rather than re-using an existing method that sometimes violates it.

There's a slight misconception that I see recurring here; it's either
widespread, or just on my part.

My understanding is that 2616, by 'cacheable POST', means that if a
POST's response carries cache directives, it may be replayed in
response to GETs on the same resource. However, it MAY NOT be
replayed in response to subsequent POSTs; they must be forwarded to
the origin.

If this is true, using POST isn't a solution, because the cache
cannot satisfy subsequent queries; they can only resubmit the POST.
This, I think, is the motivation for a separate QUERY method, whose
responses can be replayed.

All of this said, I agree with your conclusions about QUERY; it's
more trouble than it's worth (see [1]).


[1] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0236.html

Mark Nottingham
Received on Wednesday, 20 February 2002 16:14:15 UTC

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