W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1999

Re: Static? Dynamic?

From: Dan Connolly <connolly@w3.org>
Date: Tue, 29 Jun 1999 22:50:17 -0500
Message-ID: <377993F9.74A6F1D5@w3.org>
To: Mike Meyer <mwm@phone.net>
CC: www-talk@w3.org, Scott Orshan <sdo@lchome1.beasys.com>
Mike Meyer wrote:
> 
> On Tue, 29 Jun 1999, Scott Orshan wrote:
> :->Beyond Forms, though, the display of a Web page is not necessarily
> :->idempotent - it is not the same thing to retrieve it once as it is to
> :->retrieve it many times. There are simple statistics and counters that would
> :->become incorrect. Ads would be regenerated. You might repeat the
> :->shopping transaction that you just made. The act of retrieving
> :->a Web page might cause some physical action to happen - zooming
> :->a camera or shifting a production line forward - not something you
> :->would want to repeat accidentally.
> 
> There is a bit of confusion here about "display" vs. "retrieve". The
> stats & counters count retrievals - or, in the terminology of the
> HTTP/1.1 specification, requests. Any request that uses the "GET",
> "HEAD", "PUT" or "DELETE" methods is idempotent

Whoa! don't lump PUT and DELETE in with GET and HEAD! That's
missing the whole point!

> (HTTP/1.1, section
> 9.2.1).

really?
surf surf surf...
http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt.gz

indeed... PUT and DELETE are idempotent
	"the side-effects of N > 0 identical requests is the same
	as for a single request."

but I don't think that'e the relevant characteristic. What
*used* to be (erroneously) called idempotent is now called "safe."

==========
9.1.1 Safe Methods

   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.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
==========

See also
	Get and POST: what needs a URI and what doesn't
	(rough draft)
	http://www.w3.org/Provider/Style/get

and the section "Signing: From Documents to Deeds"
in
http://www.w3.org/DesignIssues/UI.html

> Well, they are supposed to be. There are lots of sites for which that
> isn't true, because following standards on the web is considered
> optional. But anyone who writes an application that uses one of those
> methods for a request that isn't idempotent has only themselves to
> blame.
> 
> Personally, I'm annoyed that HTML won't let me use an A tag to issue
> anything but a GET request. I'd love to be able to write something
> like <A HREF="/cgi-bin/change-the-world.py" METHOD=POST> to inform the
> client that this request is *not* for an idempotent page, and it
> shouldn't reissue it without checking with the user.

Huh? You would then have to change implementations to make
users aware that they're doing something they can be held
accountable for. And we already have widely understood
and implemented syntax for that:

Is there some reason that
	<form action="/cgi-bin/change-the-world.py"  METHOD=POST>
	<input type=submit>
	</form>
doesn't meet your need?


-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/
tel:+1-512-310-2971 (office, mobile)
mailto:connolly.pager@w3.org (put your tel# in the Subject:)
Received on Tuesday, 29 June 1999 23:50:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT