- 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
> 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
http://www.ics.uci.edu/~fielding/
Received on Wednesday, 25 September 1996 19:18:53 UTC