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