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
caching?


My .02

-- 
Mark Nottingham
http://www.mnot.net/
 
Received on Wednesday, 30 January 2002 20:18:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT