Re: safe reload POST?

> Roy T. Fielding:
>>
>>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.
> 
> No. There is no standard which defines the semantics of the reload
> button.  You can't accuse any browser of being seriously broken if
> it does a POST, not a GET.

Contrary to unpopular belief, I don't need an IETF-blessed standard
to tell whether something is broken or not.  Reload is a reLOAD of the
response, not a REDO of the action that generated that response
(the two may end up being the same thing for some actions).  The only
way to reload a response is to do a GET on the URI associated with
that response, which is what you can receive after a 303 or within
Content-Location in a non-GET response.  The rules are very simple --
if you have that URL, a GET on it will result in a safe and idempotent
reload regardless of the original request method.

> There is not even an ad-hoc standard.  When reload is pressed on a
> POST result, some browsers do a GET on the POST URI, some do the POST
> again, and some pop up a dialog box.  
> 
> A standard for this has been on my wish list since 1994, but nothing
> has happened so far.  Larry's proposal looks like a very good first
> step to me.

Larry's proposal in unnecessary -- HTTP/1.1 already defines the mechanisms
to do safe reloads under all circumstances.  We just have to convince the
browser developers to implement them, which should be no harder than
convincing them to do another new mechanism that hasn't been defined yet.


 ...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 Thursday, 26 September 1996 16:46:15 UTC