Re: Comments on draft-v10-03a.

Koen writes:

>Add a definition of `idempotent'.  Proposed definition:
>
>  Idempotent request
>
>    A request done with either the GET or the HEAD method.

No, the whole point of using a word to describe that condition of
"user is not asking for anything which changes the resource" is
so that we can define other methods that are also idempotent.

>The word `idempotent' is used in a very confusing way in the spec, its
>use is very different from its use in mathematics.

Okay, I'll replace it with a phrase.

>8.10  Last-Modified
>-------------------
>
>In current caching practice, this header is very important: caches use
>the heuristic that documents that contain no Last-modified, no
>Expires, and no Pragma should not be cached.

Nope, I will not include that heuristic in the spec.  It is neither
consistant nor "correct" behavior on the part of HTTP/1.0 clients;
it is simply a heuristic which will be void as soon as a better
mechanism is present.

>Alternatively, an appendix could be devoted to summarizing all caching
>implications of the protocol and describing current caching practice.

That will be done for HTTP/1.1.

>8.11  Location
>--------------
>
>Add a remark that, except in 301 and 302 responses, the URL given is
>always supposed to be accessed with the GET method.
>
>This is particularly relevant for 200 responses to POST requests.  The
>spec is currently not clear enough about this.
>
>(This also applies to the 1.1 spec.)

It only applies to 1.1 (1.0 only allows Location in 3xx responses).
In any case, from the discussion it would seem best not to add Location
to 2xx and simply provide 303 See Other instead.

>8.13  Pragma
>------------
>
>I quote:
>
>>All pragma directives specify optional behavior from the viewpoint of
>                               ^^^^^^^^^^^^^^^^^
>>the protocol;
>[....]
>>When the "no-cache" directive is present in a request message, a
>>caching intermediary must forward the request toward the origin server
>                      ^^^^
>
>Contradiction?  I believe that the consensus is that defined pragma
>headers should always be honored.  I propose to delete the `optional
>behavior' sentence.

The sentence immediately after it explains the apparent contradiction.
In this case, it is required behavior of cache mechanisms, not of the
protocol.

>10.2  Idempotent methods
>------------------------
>
>As discussed above, the word `idempotent' should be either defined in
>Section 1.3, or changed to something else like `browse-only' or
>`retrieval'.
>
>Quoting, about idempotent methods:
>
>>These methods should be considered "safe" and should not have side effects.
>
>If something `should not have side effects', one would expect it to be
>cacheable.  But GET and HEAD transactions are not always cacheable.
>
>The quoted sentence above should be changed to read
>
>  These methods should be considered "safe".

Okay.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Thursday, 31 August 1995 18:25:01 UTC