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

"Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> wrote:
>> 	Just to elaborate on that, as already stated in the HTTP/1.1 draft,
>> only the server (actually, in the case of FORMs with METHOD=POST, its CGI
>> script) can determine if a POST is idempotent, based on how the content
>> entity in the request is handled by the server/script.  Therefore, it is
>> important (IMHO) that the HTTP protocol provide for an Idempotent reply
>> header by which the client can be informed if the POST was idempotent
>> ("yes"), with the default remaining "no".
>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.

	Absolutely not!  Your earlier messages in this thread reflect
the same confusion about the entity to which POST content refers, which
I thought I had explained, but I'll try again, hopefully without being
*too* verbose. :) :)

	The HTTP/1.1 -07 draft says:

9.5 POST

The POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the resource
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
identified by the Request-URI in the Request-Line. POST is designed to
allow a uniform method to cover the following functions:


The actual function performed by the POST method is determined by the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ |||||||||||||||||
server and is usually dependent on the Request-URI. The posted entity is
||||||                                                  ^^^^^^^^^^^^^
subordinate to that URI in the same way that a file is subordinate to a
directory containing it, a news article is subordinate to a newsgroup to
which it is posted, or a record is subordinate to a database.

	Only the server can determine the idempotence of a POST
*request*, upon also receiving the particular, subordinate, "content
entity" that accompanies the *request*, and acting on it or not.  The
Cache-Control headers, or your rel, deal with a different entity,
that is associated with the server's *reply*, *not* with the "content
entity" that is associated with the *request*.

	There is nothing presently in any protocol dealing with the
disposition of that POST content entity, once it has been received and
acted upon (or not) by the server, beyond the issue of redirection.
That is, if the server returns 301 or 302, the UA should seek
confirmation and then issue another POST request including the content
entity, but if it is 303, issue a GET and not use the content entity.

	But once a server accepts the POST content entity, and changes
something (a non-idempotent action), or simply retrieves something (an
idempotent action), the headers presently returned by the server apply
to the entity (body) accompanying the server's reply, not to the content
entity which accompanied the UA's request.  Any caching servers interposed
between the UA and origin server concern themselves with that *reply*
entity, and an Idempotent: yes | no would change *nothing* for those
servers, because it doesn't apply to that reply entity.  No currently
deployed client, to my knowledge, including ones which cache reply
enties themselves, save their POST content entities to disk, or anywhere,
beyond the current session.  They would need to do so, and develop
rules and mechanisms for saving POST content entities beyond the
current session, to support bookmarking for FORM submissions with
METHOD=POST, as they presently can and actually do for FORM
submissions with METHOD=GET (by virtue of each subordinate *request*
entity being appended to the ACTION URI as ?searchpart fields).

	Here are typical bookmarks for METHOD=GET:

<A HREF="http://server/script?searchpartA">Blah A</A>
<A HREF="http://server/script?searchpartB">Blah B</A>

	Here's what that first URL really is, i.e., with implied
parameters made explicit:


	Here's a "parameterized" URL that could be used as a means
(without need for IETF standards if a particlar client restricted this
usage to it's own bookmark files, though further public discussion and
standards would be nice 8-) for bookmarking with METHOD=POST:



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

Received on Wednesday, 2 October 1996 07:55:53 UTC