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

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 UTC