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

koen@win.tue.nl (Koen Holtman) wrote:
[....]
> [Koen:]
>>>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.
>
>The 1.1 spec defines both "safe" and "idempotent" precisely.  With the
>1.1 definitions, the header name we want is "Redo-Safe", not
>"Idempotent".
>
>The "idempotent" definition in the 1.1 spec talks about _all_ side
>effects, not just unsafe side effects.  This makes "idempotent" a
>pretty useless term for discussing real-life http applications.

	Yes, I see that.  Both the HTTP/1.0 RFC and the HTTP/1.1 draft
discuss the issue of side effects for which the UA (or it's human user)
are responsible under a section labeled "Safe Methods", so "safe" is a
long established, precise term.  I'm still groping for some name for the
header which implies a status report on whether such a side effect has
occurred, but all things considered,

	Redo-Safe: yes | no

(with default no for POST) may be interpretted in that way ("If the
server replied that this can be redone safely, it must have been done
without solicited side effects this time.") and in effect covers both
bases.

	My reading of the third paragraph in Section 9.1.1 is that
side-effects, per se, are not precluded for GET, though perhaps
Section 9.1.2 contradicts this.  In any case, "unsafe" ones definitely
are precluded, which means that "Redo-Safe: no" in reply to a GET must
be disallowed, even though caching problems for GET might be addressed
via Cache-Control headers.  I also can't think of a situation in which
it would be appropriate to use Redo-Safe for changing the default
assumptions about the OPTIONS, HEAD, PUT, DELETE, or TRACE methods.
So, can/should  Redo-Safe  be restricted to POST requests, and be
ignored by the UA if received in a reply for any other method?

				Fote

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

Received on Thursday, 3 October 1996 13:37:52 UTC