W3C home > Mailing lists > Public > www-tag@w3.org > January 2002

Re: Background information on GET and XForms (was: GET should be encouraged...)

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 30 Jan 2002 17:18:24 -0800
To: Tim Berners-Lee <timbl@w3.org>
Cc: Gavin Thomas Nicol <gtn@rbii.com>, w3c-forms@w3.org, www-tag@w3.org
Message-ID: <20020130171824.B16374@mnot.net>
On Wed, Jan 30, 2002 at 12:16:39PM -0500, Tim Berners-Lee wrote:
> At the simplest end of the spectrum, one could add "querybody" to
> the list of things a response var vary on, to be put in a Vary:
> header.  But one would have to make understanding of the new
> protocol mandatory (eg by making a mandatory new header) because a
> serious failurewould be for a proxy to incorrectly return the
> results of a different header.  So there is not really any hope of
> back-compatability with proxies - the best hope is to find
> somethinmg which will make them drop out and go transparent.

Also, putting an entity body on GET, while not forbidden, will likely
break a lot of proxies; they'll either silently fail or discard the
body. A new method would be better.

> Another design question is to what extent there should be
> visibility of the query from outsideit.  There is much to be said
> for visibility into a query body, as in fact a smart cache can in
> fact figure out when it in fact has enough information to answer
> the request, even though the request does not match exactly a
> previous one.

We'd need some way to index into the entity body; for most XML, this
could be XPath (or a subset thereof). For more complex and varied
data representations (like SOAP section 5 encoding), there would have
to be a canonical form (one could possibly reference WSDL to select
the appropriate data structures in SOAP's case). Urgh.

I don't know that intermediaries would be willing to do so much work
for an unlikely cache hit; these days, AFAIK most still don't cache
anything with a query (HTTP/1.0 or not). Client caches might.

If the only purpose of this is to enable caches to optimise these
cases, it's probably not such a good idea, even though POSTs
semantics aren't a great match for these uses. I doubt whether many
will implement to take advantage of it, and meanwhile, the mechanism
lends itself to pretty bad abuses (I can see the whole world
migrating everything with a query string to QUERY now, because it's
"prettier," thereby losing addressability, etc.).

Are there other benefits of visible lack of side effects, besides

My .02

Mark Nottingham
Received on Wednesday, 30 January 2002 20:18:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:30 UTC