Re: REPOST (was: HTTP working group status & issues)
Koen Holtman (koen@win.tue.nl)
Wed, 2 Oct 1996 22:21:40 +0100 (MET)
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.