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

Larry Masinter <masinter@parc.xerox.com> wrote:
>> c. Putting 
>>   Link: <http://site/that_resource>; rel=source
>
>I agree with Roy on this one; this has clear and consistent semantics,
>and doesn't require changing the interpretation of POST.

about what "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> wrote:
>You are talking about establishing a relationship between the content
                                                               ^^^^^^^
>of the current response and a resource (identified by a URL) which
 ^^^^^^^^^^^^^^^????????
>corresponds to the meaning of the original POST request, such that the
>original request can be repeated in a safe manner.  Use
 ^^^^^^^^^^^^^^^^                      ^^^^
>
>   Link: <http://site/that_resource>; rel=source
>
>for supplying such a relationship.

	The discussion in this thread led to the clarification that
"safe" is to be treated as having been defined precisely in Section
9.1.1 of the current HTTP/1.1 draft to mean that:

	A request, upon being fulfilled by a server, may have side
	effects, but none for which the UA or it's user will be held
	accountable.

A POST request which yields side effects for which the UA/user will be held
responsible is "unsafe".  In contrast, for example, a POST that is submitted
with content which has been encoded as multipart/formdata and results in
a retrieval (no side effect for that aspect) but also increments a counter
(a side effect, but one for which the UA/user will *not* be held accountable)
is "safe".

	The initial discussion on this matter in the HTML-WG, and early
discussion here by some (certainly me), was using "idempotent" to mean
"reqests never will cause side effects for which the UA/user is accountable",
but subsequent discussion clarified that Section 9.1.2 gives idempotent a
different definition.                    

	A request for a *reply body* always will be *safe*, because that
simply would be a retrieval of a pre-existing document instance (GET
or the equivalent of a GET), *regardless* of whether that reply body was
returned for a POST *request* which was *unsafe* (was serviced in a manner
which caused a side effect for which the UA/user will be held accountable)
and/or would be *unsafe to repeat* (would again cause a side effect for
which the UA/user is responsible).  How a link for:

	(1) requesting a *reply body* ("the content of the current response",
	    with only possible changes in headers) from a prior POST

might be structured, and how a link for:

	(2) repeating an actual POST request with the same Post-Content

might be structured, are relevant to this discussion, but side-issues with
respect to the HTTP procotol, per se.

	What is not a side-issue, is the present *absence* from the HTTP
protocol of any means by which a server can inform the UA about whether
or not a POST request caused, and/or if resubmitted would cause, a
side-effect for which the UA/user will be held accountable.  We are
not talking about a change in the semantics of POST, but a means by
which a server can provide that information to the UA.

	If it is not provided, the UA must continue to *assume* that
the POST request *might* be unsafe, and thus *always* seek confirmation
from the user during the current session.  By extension, it must *always*
seek confirmation in conjunction with any scheme it devises to support
bookmarking of POST requests for submissions to the server as a POST
request with the same Post-Content.

	So I'm still crossing my fingers that a means for the server to
provide this important information to the UA is added to the HTTP protocol.
Also, just as I was about send this message I got those from Koen
indicating that at least two people would consider a header such as
Redo_Safe: yes | no   an important addition to HTTP/1.1. :) :)

				Fote

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

Received on Saturday, 5 October 1996 12:16:46 UTC