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).
>
>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'?

	I don't have an adequate grasp of all the considerations that
apply to intermediate caching servers, but at least for communications
between the client and origin server, I think the "solution" is already
there and simply needs to be implemented.  URLs in principle can have
";parameter" fields appended to the "/path" field.  So in principle
you could have (split for readability):

	http://www.pizza.com/cgi-bin/order;idempotent=no
		?num=1;size=large;topping=pepperoni+onion

	That's a perfectly fine "bookmark" which a "parameter aware"
client could handle equivalently to what it does for resubmission
requests when forms have METHOD=POST.  The parameter should be treated
like a "#fragment" and not be included in the GET request line sent to
the server.  It might be helpful, though, to have the client send a
request header which confirms that it reconizies the non-idempotence of
the GET request.

	If the original FORM had:
	
	ACTION="http://www.pizza.com/cgi-bin/order;idempotent=no"

currently deployed clients would include the parameter as part of the
GET request, so a "next-generation" server would thereby know that
the request is from a client unaware that the request is not idempotent,
and could itself inititate some kind of confirmation procedure (have
to think about that some more 8-).

	In any case, if ";parameter" fields started being used formally
in http URLs, one could develop rules for treatment by clients as if
they had been received in a server's reply, versus ones to be handled
as or via the client's own request headers (or both, or neither, depending
on the parameter name).

	At present, the only formalized URL parameter is for ftp
(;type=[A, I or D]).

				Fote

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

Received on Wednesday, 25 September 1996 07:05:50 UTC