RE: draft findings on Unsafe Methods (whenToUseGet-7)

The issue of safe HTTP request methods and "safe"
responses was discussed at length in the HTTP working
group. It was noted that the request method is not
the determiner of safety, but rather the server was
the final arbiter. RFC 2310 ("The Safe Response Header
Field") was proposed as one way that the origin server
could note the safety of methods. The interesting observation
was that most of the use cases only required knowledge
of safety after the fact, and not a priori.

>  A great deal of the utility of the Web depends on the 
> ability of users
>    (and agents) to explore the shared information space safely; to
>    explore a page and come back, without channging anything. A very
>    important principle when designing Web applications is:
>      * safe methods (GET/HEAD) should be used for safe operations:
read,
>        query, view, ask, lookup
>      * safe methods must not be used for unsafe operations: write,
>        update, modify, tell, buy, agree

This wasn't supported in the use cases we looked at. Whether
or not the GET method was "safe" was up to the server. Servers
should, of course, be aware that there will be applications
(web crawlers, cache warmers, etc.) that will pre-fetch GET
data. 

It may be that you mean something other than "safe", such as
"freely callable without worry", whether or not the results
actually are safe.

I don't find anything in the design of GET and HTTP that
supports your conclusion, that the "get" method should be
used when the "form is idempotent". In fact, it isn't a
property of the form at all, it's a property of the processor
of the form at the time the form is processed, to decide
whether the form submission is or isn't idempotent.
And there's no use case for having client software, search
service crawlers or caching proxies automatically submit
forms in advance, whether or not they are "idempotent".

Received on Monday, 15 April 2002 16:45:55 UTC