W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: REPOST (was: HTTP working group status & issues)

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 2 Oct 1996 22:21:40 +0100 (MET)
Message-Id: <199610022121.WAA06654@wsooti04.win.tue.nl>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: fielding@liege.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

My take on this issue:

We want to use POST instead of GET for many forms because of i18n
considerations.  A problem is the `repost form data?' popups which
confuse the user.  The service author should be able to eliminate
these popups if he knows that reposting is always safe.

If I understood his messages correctly, Roy has proposed several ways
to do this:

a. 303 responses.  This will work, but 303 responses add a RTT
penalty, so I don't think this is a solution.

b. Putting 

  Content-Location: url_to_GET_the_previous_result_from 

in the response.  This would work _if_ the 1.1 spec would guarantee
that the URL supplied in the Content-Location header serves the
previous result of the POST request.  But I can find no such guarantee
in the spec.  Anyway, I don't like having to create new resources to
eliminate the `repost form data' popups.

c. Putting 

  Link: <http://site/that_resource>; rel=source

in the response.  I don't know if this will give the guarantee missing
for Content-Location, but in any case it not part of 1.1 and is a bit
too twisted for my taste.  And I still would have to create new
resources.


I think Foteos is right in assuming that we are dealing with a
property of POST requests which is not covered by any existing 1.1
protocol element.  `Idempotent: yes' does not duplicate anything we
already have.

Note however that the POST request property we are _actually_
interested in, which is `safe to redo the POST', is not equivalent to
idempotence.  For example, a POSTable search engine with a use counter
in the result page is _not_ idempotent (because posting always has the
side effect of updating the counter), but it _is_ safe (because the
user is not held accountable for the consequences of this side
effect).

Thus, introducing a `Redo-Safe: yes' header would make more sense
than `Idempotent: yes'.

Koen.
Received on Wednesday, 2 October 1996 14:28:12 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:14 EDT