Re: REPOST (was: HTTP working group status & issues)

koen@win.tue.nl (Koen Holtman) wrote:
>Foteos Macrides:
>>  I'm still groping for some name for the
>>header which implies a status report on whether such a side effect has
>>occurred,
>
>Why would you want such a status report in a header?  If you know that
>a redo is safe, you can also store the form you just submitted in a
>hotlist.

	I'm not sure what you mean by "store the form".  First let's
put aside discussion on how to bookmark a link for the reply entity
(body) from a server to which a POST request was sent.  That link is or
can be treated as a GET, and there's no issue of safety/accountability
involved.

	For bookmarking of links associated with FORMs that have
METHOD=POST and are intended to permit submission of particular
Post-Content without need to render the FORM markup and have that
filled out again, you must store the Post-Content in a manner which
allows it to be associated with the Request-URI that had been specified
as the FORM's ACTION, as well as set up some way to make clear to the
UA's code when that bookmark is activated sometime in the future that
the METHOD for the request should be POST (not GET), and what to send
in the Post-Content-Encoding header (which might not be the default
application/www-form-urlencoded).  Those are the mimimum necessary
requirements.  The same issues apply to resubmissions via the history
stack during the current session, in which case those three minimum
requirements are already know/stored, but not presently saved beyond
the current session for most (all?) deployed clients.

	A FORM can be submitted multiple times, with variations in the
content, based on how it's been filled out.  In the case of METHOD=GET
this will create a family of URLs of the form Request-URI?searchpart
with variations in the ?searchpart, *all* of which are "safe", because
only retrieval without accountability for any side effects is permitted
for GET requests.  In the case of METHOD=POST, this will create a family
of Request-URI-plus-subordinate-Post-Contents, some of which may be
"safe", and others of which may be "unsafe", and this additional
information must be associated with each Post-Content in the history
stack, and any bookmarking scheme for POST requests -- assuming the
IETF were kind enough to provide a means for the server to return this
information via an new header in the HTTP/1.1 protocol.  At present all
of the Post-Contents must be assumed to be "unsafe", simply because they
*might* be "unsafe", with no information to the contrary.  But, for
example, a FORM with METHOD=POST might solicit a username/password
and/or personal information, and on submission return the entry
document for a company's product catalog.  That Post-Content was
and would forever be "safe" in the sense we are discussing.  The FORM
might also have a checkbox for having a hardcopy of the catalog sent COD.
If checked, that Post-Content was and would forever be "UNsafe" in
association with the Request-URI to which it was subordinate.  The user
can resubmit the first Post-Content freely during the present session,
or in future ones via a bookmark, but should be warned about resubmitting
the second during the current session, or about bookmarking and perhaps
later ordering another hardcopy COD inadvertantly.

	We *are* talking about regulation of "redo" possibilities,
and Section 9.1.1 *does* equate "safe" with "the UA/user is not
accountable for any side-effects".  So  Redo-Safe: yes | no  is
"correct".   But given that headers can be added in a line or so of
a CGI script, I'd personally feel more comfortable about something
like  Accountable: yes : no  with default "yes" for POST.

	I can image CGI author's putting a line for sending a
Redo-Safe: yes  header without code to check for whether the COD
hardcopy request has been checked, than an  Accountable: no  header.
The latter makes it more likely that the point of the header really
is understood before adding it, because it more clearly implies
what's intended -- from a provider's perspective, whether or not the
provider has read Section 9.1.1.  It implies more clearly that the
provider is absolving the UA/user of accountability, should a COD
order result from the POST request.  That's all I'm trying to get
across.

				Fote

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

Received on Saturday, 5 October 1996 16:24:02 UTC