Re: safe reload POST?

Larry Masinter <masinter@parc.xerox.com> wrote:
>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:
>
>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).

	A request header of this general sort, or a REPOST method as
you subsequently suggested, could be useful, but perhaps discussion of
such a header's purpose and syntax, or a new method, might better be
put off until the result header issue is resolved.


>b) new result header that marks whether a result
>   is reloadable without warning, with three values:
>
>   1) reloadable without warning (default for GET)
>   2) not reloadable without warning (default for POST)
>   3) not reloadable without warning, UNLESS reloading
>      header (a) is supplied.
>
>In the third case, it is the SERVER that decides whether a particular
>reload is safe, or implements the warning.
>
>It would still be the case that a POST which results in an error
>(timeout, etc.) cannot be reloadable without warning, and that for
>some HTML forms. It's a minor point, but equivalent GET form would be
>reloadable without warning. (e.g., "search form to heavily loaded
>server").
>
>Note that I'm avoiding the ratsnest of "idempotent" and "cachable".
>
>Is a bookmark a 'reload'?

	Bookmarking in relation to i18n implementation is what started
us on this issue in the HTML-WG before you raised it more generally here,
and is a good example of why it's inappropriate to conceptualize this
in relation to the ambiguous concept of a "reload".  Most bookmarking
schemes now use an HTML file with a URI as the HREF for an Anchor.
Activating that link *may* cause a previous document instance to be
restored on the user's screen for review, or may yield a new document
instance, which may or may not be the same as the previous, all depending
on the nature of the URI, the caching design of the client, whether any
caching servers are interposed, and a variety of factors associated with
cache handling.  With this design, a GET or its equivalent will be
performed.  So let's discuss GETs first.

	Suppose the user filled out an Alta-Vista search FORM, which
presently uses METHOD=GET.  The search will return a "hit list" in
some manner, and that "resource" could be represented by a URI which
corresponds to the FORM's ACTION, with a ?searchpart appended which
corresponds to the encoding of the user's form entries.  Suppose
a Content-Location header were included, with a URI pointing to
where that particular "hit list" can be retrieved (presumeably as
as cache, and presumeably with an expiration and other cache-related
parapernalia).  Now the user initiates some procedure for "saving"
a bookmark.  What should be saved, the Content-Location URI for
"review" of that particular hit list, or the ACTION URI with the
?searchpart appended for "resubmission" of that search request,
perhaps next month to see what's new in the database without the
need to fill out the FORM, identically, again???  A smart client
of the future might offer the user a choice of what to save.  Most
(all?) currently deployed clients will save the latter.

	When the user activates such a link next month, it is not
expected that the "hit list" will be the same as that which was
received today, because Alta Vista will have updated it's database.
This is not a violation of idempotence for GET, because, as was
explained in our discussions in the HTML-WG,

	"David W. Morris" <dwm@shell.portal.com> wrote:
	... the user's REQUEST does not effect the outcome
	of the NEXT use of the same REQUEST.  Other external
	events cause the change in outcome.

Now, i18n (http://www.alis.com:8085/ietf/html/draft-ietf-html-i18n.txt) says:

5.2. Form submission

   The HTML 2.0 form submission mechanism, based on the "application/x-
   www-form-urlencoded" media type, is ill-equipped with regard to
   internationalization.  [...]

   The best solution is to use the "multipart/form-data" media type
   described in [RFC1867] with the POST method of form submission.[...]

   One problem [...] is that current browsers do not generally allow for
   bookmarks to specify the POST method; this should be improved.[...]


So suppose that a search service such as Alta-Vista offered a FORM with
METHOD=POST ENCYPE="multipart/form-data" for a database with all of
the world's URIs saved in a universal charset so that submitted content
can use any charset and be converted for a charset (language) independent
search of the database.  Suppose, also, that it's reply includes a
Content-Location header, whose URI could be saved as a bookmark for use
with GET or its equivalent to "review" that particular hit list, but the
user wants to save the *equivalent* of <ACTION-URI>?searchpart for use
next month.  POSTing next month with an identical content *would* be
idempotent, even though HTTP/1.1 requires the assumption that it is not.


	To support what is being recommended for i18n, and enable the
above, a client must save the *content* that was orginally POSTed (*not*
the URI pointed to by a Content-Location header accompanying the server's
reply to the POST, *nor* the particular document instance to which it
points) -- because that *content* is the equivalent of the ?searchpart
that's being "saved" when the METHOD=GET.  Saving POST content to be
associated with bookmarks adds another strain on already overtaxed
resources, particularly since such content could be substantially large
and in many cases, unlike this example, the POST is not idempotent and
"saving" it for reuse would be ill-advised (and a large number of
Webizens couldn't make a sound judgement on the matter if asked by
the UA).  It would be extremely helpful if, in conjunction with the
conversions of idempotent FORMs from METHOD=GET to METHOD=POST, in
the interest of i18n, they also could sent and Identpotent: yes
header, to inform UAs in a straightforward way that it can still be
treated "as if" it had METHOD=GET.

	As far as allowing Idempotent: no for GET is concerned, I
do think that with appropriate caveats about it being "non-binding"
and to be used judiciously, the Web could live with it, but the
more pressing issue (IMHO) is support of Idempotent: yes for POST,
and since the default for POST is no, there's nothing "dangerous"
about that for older clients and servers.

				Fote

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

Received on Friday, 27 September 1996 13:46:26 UTC