draft findings on Unsafe Methods (whenToUseGet-7)

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
       (mylist-request@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<--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 15 April 2002 11:50:36 UTC