W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Comments on draft-v10-03a.

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 30 Aug 1995 14:03:18 +0200 (MET DST)
Message-Id: <199508301203.OAA00533@wswiop04.win.tue.nl>
To: Roy Fielding <fielding@beach.w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Koen Holtman <koen@win.tue.nl>

Below are some comments on

  http://www.ics.uci.edu/~fielding/test/draft-v10-03a.ps.gz .

Most of the comments apply equally to earlier drafts of the HTTP/1.0 spec.

If a comment also applies to the draft HTTP/1.1 spec, a remark between
brackets is made.  I will comment more fully on the draft HTTP/1.1
spec in a future message.

1.3 Terminology

Add a definition of `idempotent'.  Proposed definition:

  Idempotent request

    A request done with either the GET or the HEAD method.

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

Defining it would eliminate some of the confusion, but not all of it.
A better way to eliminate the confusion would be to use another term
like `browse-only request' or `retrieval request' instead of
`idempotent request'.

One could argue that it is too late to change `idempotent' to
something else in the 1.0 spec.  (IMO, it should definitely be changed
in the 1.1 spec.)

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.

A vast number of CGI scripts producing dynamic output depend on this
heuristic to be used.  We are talking about a best-current-practice
document, so I feel that this heuristic should be recorded somewhere,
for example in a note at the end of Section 8.10:

  Note: For reasons of downwards compatibility with old CGI scripts,
  it is suggested that caches do not cache HTTP/0.9 and HTTP/1.0
  responses that contain no Last-Modified, no Expires, and no Pragma

(The note above could also be put into the 1.1 spec.)

Alternatively, an appendix could be devoted to summarizing all caching
implications of the protocol and describing current caching practice.
I think I have enough material to be able to write a first draft of
such an appendix within a few days.  Roy, if you want such a draft,
tell me.

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

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.

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

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

Saying `should not have side effects' in one paragraph, and then
weakening this to `should not have unexpected/unrequested side
effects' in the next paragraph is too confusing.

(this also applies to the 1.1 spec)

Received on Wednesday, 30 August 1995 05:05:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC