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

Re: safe reload POST?

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Wed, 25 Sep 1996 18:59:04 -0700
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9609251859.aa07890@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1626
> After doing a case analysis ("original request failed", "original
> request succeeded") x ("reload with warning", "reload without
> warning"), I came up with the following proposal:

I think you are mixing browser semantics and behavior with protocol
semantics.  It would make far more sense to just define an optional
transaction ID and allow the application to send that id if they
are concerned about repeating a transaction request that was never
completed to the client's satisfaction.

> a) new optional request header that marks a request
>    (GET, POST, etc.) as an 'unwarned retry'. This header might be
>    generated by requests from pressing [Reload] on a browser.
>    Syntax? (dunno).

Pressing "Reload" on a browser means "perform an unconditional GET
on this resource."  Any browser that performs an action other than GET
as a result of the Reload button being pressed is seriously broken.
The GET may be performed on the redirected resource (e.g., 303 see other)
or on the returned Content-Location or on the original request-URI.

 ...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, 25 September 1996 19:18:53 UTC

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