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

I suppose thedecision as to whether QUERY should be introduced or GET
expended depends on how much they will share.

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.

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.

Tim

----- Original Message -----
From: "Gavin Thomas Nicol" <gtn@rbii.com>
To: <w3c-forms@w3.org>
Cc: <www-tag@w3.org>
Sent: Tuesday, January 29, 2002 2:36 AM
Subject: Re: Background information on GET and XForms (was: GET should be
encouraged...)


> On Monday 28 January 2002 04:04 pm, Tim Berners-Lee wrote:
> > In the future, this does call for a new GET-with-body or QUERY or
> > whatever you like to call it, which would be defined as an operation
> > without side effects (a function) of both the URI  and the
> > message body.
>
> GET is (largely) defined that way in HTTP 1.1. The spec does not deny
> the body of a GET request. Also HTTP 1.0 allowed it, and HTTP 1.1
> claims to be backwardly compatible.
>
> Some clarification of semantics *would* be nice to have though.
>
> > (I prefer QUERY to an adaptation of GET, myself).
>
> Shades of HTTP2... I prefer this too... though I wonder about the
> impact on proxies and firewalls.
>

Received on Wednesday, 30 January 2002 12:16:31 UTC