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. :) :)

It doesn't -- read it carefully.  The response is all you have to work
with and the header fields are part of its content.  It is the second
part about "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", that is exactly what you asked for.

> 	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*.

Nope, that only applies to Content-Location.

> 	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.

That is wrong.  The entity headers apply to whatever the server wants
them to apply within the scope of HTTP semantics.  The definition of Link
is such that it establishes relationships between *things*, and one of
those things can most certainly be a URL corresponding to the semantic
content of the request URL+entity, such that the original POST request
can be repeated as a GET request.  Since the server creates the URL,
there is no ambiguity and no i18n concerns, and the later request is
guaranteed to be safe (or at least the server's fault if it isn't).


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 2 October 1996 19:16:28 UTC