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

"Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> wrote:
>> "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.
                      ^^^^          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	No, that it not what I asked for.  Others, including you, brought
those higher order issues into the discussion, and I cautioned against
continuing in that vein.

	What I asked for, from a client implementor's perspective,
is a reply header which acts as feedback -- that *only* the origin
server can provide to the UA -- about whether a request which the server
acted upon had side effects for which the UA (or it's human user) will
be held accountable.  I need that inform, simply and specifically *that*
information, to be used in conjunction with other information which
would *already* be available, for designing code that regulates the UA's
displays, messaging, bookmarking, and its disposition of any post-content
that was subordinate to the Request-URI.  I suspect that other client
developers would find that explicit feedback useful as well, and there
is nothing presently in the HTTP protocol which provides it.  It presently
*requires* the *assumption* that the request had such a side effect,
whether or not that was, in fact, the case.

	One, not the only, but an important, use of this feedback will
be in relation to development of procedures for bookmarking of requests
that were made based on FORMs with METHOD=POST, to support an ENCTYPE
more compatible with the objectives of i18n, but for other objectives
as well (as I indicated in my example of a nucleotide sequence database
search with a large query sequence submitted via an INPUT TYPE=FILE).
Procedures for saving the post-content in conjunction with bookmarks,
and for associating it with a Request-URI on subsequent activation, need
to be developed, and perhaps REL attributes would be helpful in some
bookmarking schemes, though it did appear to me from what you wrote
that you are suggesting it's use as an attribute in a LINK tag, which
is a HEAD element and might be difficult to deal with as an extension
of existing bookmaking schemes, for which UAs also act as HTML editors
(more or less effectively, using "ad hoc" parsers 8-).

	In any case, that's a secondary issue.  What's needed immediately
for the HTTP protocol, IMHO, is a presently missing header which provides
specific feedback to the UA on whether a server has handled a request in
a manner which had side effects for which the UA (or its human user) will
be held accountable.  Ideally, is will not be burdened with overt or
implied instructions on how any UA de jour should behave when one or
another of its "buttons" is pressed, which could be counterproductive
rather than helpful.

				Fote

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

Received on Thursday, 3 October 1996 07:24:37 UTC