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

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

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Wed, 02 Oct 1996 19:25:12 -0700
To: Koen Holtman <koen@win.tue.nl>
Cc: Foteos Macrides <MACRIDES@sci.wfbr.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9610021925.aa00406@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1686
> 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.

Given the scope of "the problem", I see no reason why a RTT penalty
matters.  Using 303 also results in better cache hits, which would
offset the penalty in the rare cases that this is ever needed.

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

You don't "create new resources" -- they just exist.  The URL would be
interpreted by the same mechanism that interpreted the original POST --
the only difference being that the parameters are preselected and
probably encoded.  If the script is capable of knowing whether or not
it is idempotent, then it is capable of understanding that each one
of its idempotent aspects corresponds to a "resource" by definition.

In any case, the real problem with using Content-Location for what is
being discussed (a redo instead of a reload) is that it would interfere
with content negotiation.

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

It is more part of 1.1 than any other solution being discussed -- see the
appendix.  More importantly, it is part of the original HTTP design and
not just another midnight hack job.  Besides, it gives you something
to put in the bookmarks file.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Wednesday, 2 October 1996 19:32:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC