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

Re: Major errors in Caching and Cache-Control

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 4 Jun 1996 15:32:19 +0200 (MET DST)
Message-Id: <199606041332.PAA08780@wsooti06.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: fielding@liege.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul:
>
>Since Roy has complained several times about the Cache-control
>section, I guess I owe him a response ... even though I agree
>with Larry that the timing is a little odd,

It is much more odd that the only-if-cached etc stuff was introduced
in the 02 draft without any discussion on the mailing lists in the
first place.

The only rationale I remember hearing for not nuking these features
immediately, as I proposed when 02 appeared, was that it would take
more editorial work to re-introduce them, once it was established that
people actually wanted them, than it would take to delete these
features at the last possible time.

Discussions about what is more odd aside, I share Roy's opinion that
no-transform is fatal:

    [Roy:]
>   "no-transform"
>      is completely wrong because it talks about content codings
>      in a way that only transfer codings are allowed to behave, and
>      thus CONTRADICTS other sections.  THIS IS FATAL (and isn't needed).
>
[Jeff:]
>Please discuss the wording with the Digest Authentication folks,
>who believed that this was a necessary feature.

I commented on this one earlier, in 
http://www-uk.hpl.hp.com/people/ange/archives/http-wg-archive/1013.html:

  10.7.6 Miscellaneous restrictions

[This is 14.9.5 in the current draft]

  In certain circumstances, an intermediate cache (proxy) may find it
  useful to convert the encoding of an entity body. For example, a proxy
  ^^^^^^^^^^^^^^^^^          
  might use a compressed content-coding to transfer the body to a client
  on a slow link.

 This implicitly allows conversion of entity bodies by proxy caches.  I
 don't think this was ever allowed before, and in any case it breaks
 range retrieval (afaik, range requests work on the entity data in the
 response, not on the unencoded version of this data.)

I think Roy has the same problem with no-transform that I have: it
disallows a conversion that should never be allowed in the first
place.  14.9.5 is fatal and must be deleted. Along with it,
"no-transform" must be deleted.

I also would like "only-if-cached" and "min-vers" to go, though I do
not think it is fatal if they stay.  I can live with the other things
as they are.  I advise against tinkering with "must-revalidate" and
"proxy-revalidate" this late in the process.

>-Jeff

Koen.
Received on Tuesday, 4 June 1996 06:36:17 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:02 EDT