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

koen@win.tue.nl (Koen Holtman) wrote:
>My take on this issue:
>
>We want to use POST instead of GET for many forms because of i18n
>considerations.  A problem is the `repost form data?' popups which
>confuse the user.  The service author should be able to eliminate
>these popups if he knows that reposting is always safe.
>
>If I understood his messages correctly, Roy has proposed several ways
>to do this:
>
>a. 303 responses.  This will work, but 303 responses add a RTT
>penalty, so I don't think this is a solution.
>
>b. Putting 
>
>  Content-Location: url_to_GET_the_previous_result_from 
>
>in the response.  This would work _if_ the 1.1 spec would guarantee
>that the URL supplied in the Content-Location header serves the
>previous result of the POST request.  But I can find no such guarantee
>in the spec.  Anyway, I don't like having to create new resources to
>eliminate the `repost form data' popups.
>
>c. Putting 
>
>  Link: <http://site/that_resource>; rel=source
>
>in the response.  I don't know if this will give the guarantee missing
>for Content-Location, but in any case it not part of 1.1 and is a bit
>too twisted for my taste.  And I still would have to create new
>resources.

	This perhaps still confuses two different things that current
UAs do not distinguish clearly when handling FORMs, but UAs of the
future should.  Here are two "parameterized" bookmark URLs to
illustrate this:

	http://server/script;method=post
		;post_content-type=multipart/formdata
		;content-location=path_to_previous_reply
                 ^^^^^^^^^^^^^^^^         ^^^^^^^^^^^^^^
	http://server/script;method=post
		;post-content-type=multipart/formdata
		;post-content=path_to_contentA
                 ^^^^^^^^^^^^         ^^^^^^^^

The first refers to a "cache", in the conventional sense, of
the *reply* entity (body) from the previous submission, whereas
the second refers to the set of information needed to repeat
the submission for a new reply.


>I think Foteos is right in assuming that we are dealing with a
>property of POST requests which is not covered by any existing 1.1
>protocol element.  `Idempotent: yes' does not duplicate anything we
>already have.
>
>Note however that the POST request property we are _actually_
>interested in, which is `safe to redo the POST', is not equivalent to
>idempotence.  For example, a POSTable search engine with a use counter
>in the result page is _not_ idempotent (because posting always has the
>side effect of updating the counter), but it _is_ safe (because the
>user is not held accountable for the consequences of this side
>effect).
>
>Thus, introducing a `Redo-Safe: yes' header would make more sense
>than `Idempotent: yes'.

	The concept of "safe" is subject to a variety of interpetations,
in contrast to "idempotent", which can be defined precisely.  We can
define a POST as "idempotent" if it "resulted solely in a retrieval, or
only in side effects for which the UA will not be held responsible" to
cover the above -- which is how it already is used *in practice* -- a
FORM with METHOD=GET could (and at many sites does 8-) cause a counter
change on submission, but is considered idempotent by current standards.
The POST in that case was the full equivalent of a GET with ?searchpart
and thus can be handled equivalently by the UA on resubmission requests
from its human user.  But if you use the term "safe" instead of a precisely
defined term with a very restricted meaning, you may be perceived as
asking for judgments beyond what's appropriate for the origin server
(a.k.a, CGI script author), alone, to make on behalf of the UA and its
human user.

	But still, if  Idempotent: yes | no  doesn't fly, then
Redo-Safe: yes | no   would at least be better than zilch.  :) :)


	Let's take the case of a POST with ENCTYPE=multipart/formdata
which includes a file that contains a large nucleotide sequence (too
large for inclusion as a ?searchpart with METHOD=GET), to be submitted
for a FastA or Blast search of an NCBI nucleotide database.  The NCBI
may well count number of submissions to its search service (to help
justify this service to Congress 8-) and may well also report that this
is the 10 millionth search it's done (for good public relations 8-),
together with the results of the FastA or Blast search.  This is still
what we "really" mean by "idempotent", in contrast, for example, to
a POST with ENCTYPE=multipart/formdata of a nucleotide sequence for
*addition* to the NCBI's database.

				Fote

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

Received on Wednesday, 2 October 1996 16:47:18 UTC