W3C home > Mailing lists > Public > ietf-discuss@w3.org > February 1999

Re: Last Call: HTTP Extension Framework to Proposed Standard

From: Koen Holtman <koen@win.tue.nl>
Date: Thu, 18 Feb 1999 11:28:24 +0100 (MET)
Message-Id: <199902181028.LAA29385@wsooti08.win.tue.nl>
To: fielding@kiwi.ics.uci.edu (Roy T. Fielding)
Cc: Koen.Holtman@cern.ch, frystyk@w3.org, iesg@ietf.org, ietf-http-ext@w3.org, discuss@apps.ietf.org
Roy T. Fielding:
>The extension framework must not automatically prevent caching.
>There is nothing in Henrik's draft that prevents an extended request
>or response from including the EXISTING cache control mechanisms of
>HTTP/1.1.  It is not necessary, nor is it desired, for the draft to
>assume that an extended message is not cachable just because some
>particular extension might not be cachable.  Therefore, your suggested
>changes are contrary to the design of HTTP.


My main concern about caching in the current draft is that some of the
MUST/MAY/SHOULD rules in there (see my comments sent to the IESG) will
sometimes cause the caching directives of upstream servers, which
generated the content, to be violated by downstream caches.  This is
unacceptable to me.

Caching is like security: you should either provide a protocol which is
correct in all cases or you should not provide it alltogether.

This is separate from the issue that some extensions could _want_ to
violate upstream caching directives.  I see no reasons to disallow
this but this use case cannot be used as an excuse for the broken
MUST/MAY/SHOULD rules which apply to all extensions.

The MUST/MAY/SHOULD text in the draft can be fixed, and I am trying to
work on this with Henrik, but I have no idea whether we will
converge.  I do feel that Henrik is not treating the issue with the
care it deserves.

I have other concerns in that the draft is very sketchy and sometimes
misleading in caching advice to implementers, but these are of a lower
order than the glitches in the MUST/MAY/SHOULD discipline.

Received on Thursday, 18 February 1999 05:37:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC