This got some discussion in today's telcon, but folks haven't really had a chance to read it; I'm trying to figure out whether I'm mostly done and should just polish off the few remaining @@TODOs, or whether the essential guts need work.

DRAFT Findings on Safe Methods on issue whenToUseGet-7

DRAFT by Dan Connolly, for the TAG $Revision: 1.5 $ of $Date: 2002/04/15 14:26:17 $ by $Author: connolly $

http://www.w3.org/2001/tag/doc/get7

text copy:

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

Though the principle applies to ftp (CHDIR and RETR are safe; PUT is not) and other protocols, most Web applications are built using HTTP; it is critical to build these applications with an awareness of the following section of the HTTP specification:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

[4]9.1.1 Safe Methods, HTTP 1.1

[4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1

It is also very important to keep this principle in mind when using HTML forms:

The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.

[5]17.13.1 Form submission method of HTML 4.01 (text has been in HTML spec back to [6]HTML 2.0)

[5] http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.1 [6] http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.2

Applications that depend on safe methods

A wide variety of applications depend on the safety property of HTTP GET: * search service crawlers * caching proxies

not to mention the importance of the ability of users to explore safely. (@@cite stats about the popularity of the back button)

Example: mailing list subscription

Consider the following two designs for mailing list subscription confirmation; in the first case: 1. The user sends a subscribe message to an administrative mailbox (myli...@example.org). 2. The list processing software requests confirmation by email, including a link to a confirmation page 3. The user visits the confirmation page, and finds a "[Confirm] your subscription" form, with method="POST". 4. The user activates the [Confirm] form control. 5. The list processing software confirms the subscription.

In the second case: 1. as above 2. as above 3. The user visits the confirmation page and sees "your subscription is confirmed". The list processing software confirms the subscription.

The latter design performed an unsafe operation (list subscription) in response to a request with a safe method (following the link from the mail message with GET).

--8<--