Re: safe reload POST?

koen@win.tue.nl (Koen Holtman) wrote:
>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.
>
>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.  

	Arbitrarily converting a POST to a GET on resubmission seems
equivalent to doing what is specified for 303 redirection on receipt
of 301 or 302 redirection.  It may be what some deployed clients do,
and users of those clients may come to see it as a "feature", but it
doesn't make sense once you think about it, and shouldn't continue
to be done arbitrarily.


>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.
>
>This has nothing to do with the safety (or idempotence as it was
>called) of GET, and has little to do with caching.  This is about
>resubmitting potentially unsafe requests due to the pressing of the
>reload button or due to navigating back in the history list.

	The concept of a "reload button" is UA-specific, and could
be misleading, as is a "history list".  A user of a UA may wish to
"review" what was returned following submission of a FORM, whether
or not resubmission of it with identical content (POST) or ?searchpart
(GET) would have the same consequence or cause the same document
instance to be returned.  A UA may or may not be able to restore a
display of the earlier document instance, and if it can, may or may
not do it via a "button" press or via a mechanism labeled "reload"
or "history".

	A user of a UA might take some action which would cause
repetition of a POST with identical content, or of a GET request with
an identical ?searchpart appended.  The UA must make a judgment about
whether to just go ahead and do it, or seek confirmation before taking
action, and the range of considerations for that have become very
complicated, both for the UAs, and for users of UAs (i.e., for most
users on today's Web, their confirmation would not necessarily be
based on an adequate understanding of the considerations involved).
The convention has been to just go ahead and take action for GET
requests with identical ?searchpart, but seek confirmation for a
POST with identical content (i.e., assume idempotence for GET,
and not for POST).

	It would be highly desireable to have a way of communicating
to UAs whether such resubissions are "safe" (idempotent?), which can
in turn be communicated to the user of the UA in a manner which is
unambiguously a "warning".  The burden of responsibility should remain
with the origin server (or author of the CGI script it executes).
The claim that a GET resubmission with identical ?searchpart is
unsafe need not be valid (if it were a spoof, the UA should still
treat it as unsafe and issue the warning), and if it were valid
(came from the origin server or CGI author), should not relieve
the origin server or CGI author of "responsibility" should the
resubmission be made inappropriately.  Coversely, the claim that
a POST resubmission with identical content *is* safe (idempotent?)
*must* be authoritative (reasonably spoof-proof). A header mechanism
for doing that therefore is desireable.  However, the header name
should reflect the protocol concept, not particular UA features or a
UA's labels for those features.
	
	Idempotent:    yes | no    seems good (IMHO 8-),
	Resubmittable: yes | no    still says what's intended, perhaps,
	Reloadable:    yes | no    is ambiguous (confuses review versus
				    resubmission issues).
		
	The problems brought on by random URL services got dealt with
via cache control headers.  The problems brought on by "tricks" that
involve non-idempotent GET requests are more difficult to solve, though
why not offer people determined to use them the opportunity to pass UAs
a "hint" about the situation?

	But most importantly, it can be anticipated that a growing number
of idempotent FORMs that might currently use GET will instead use POST
in the interest of i18n (i.e, with ENCTYPE="multipart/form-data"), and
it would be nice to have a simple, reasonably spoof-proof way of indicating
their idempotence to UAs, so that the users of the UAs needed not be
warned or prompted for confirmations unnecessarily, and so that UAs
might use it for decisions about whether to retain the content for
possibly expanded bookmarking mechanisms.  Just give the UAs the
information about the "safety" of such resubmissions, not instructions
on what to do about/with it.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 26 September 1996 12:17:45 UTC