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

Re: cookie draft available

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 17 Apr 96 15:21:28 MDT
Message-Id: <9604172221.AA07989@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
One comment on this:

   * Cache-control: Max-Age=0 or Expires:<a date in the past>.
     (Example: Expires: Thu, 01 Jan 1980 00:00:00 GMT), to ``pre-
     expire'' a cache entry.  The resource may be cached, but the cache
     must validate it before returning it to the client.

The word "must" here is not accurate if "max-age=0" is used.  The
protocol explicitly allows caches to "cheat" on expiration dates,
not because I think it's a good idea, but because people have insisted
that they will do it anyway.

Although there is some residual grumbling about it, the latest version
now includes a "must-revalidate" Cache-control directive, which seems
to be more appropriate for what you are trying to do here.  So I would
replace that paragraph with these three:

   * "Cache-control: must-revalidate", which means that the
     resource may be cached, but the cache must validate it before
     returning it to the client.

   * "Cache-control: Max-Age=0", to ``pre-expire'' a cache entry.  The
     resource may be cached, but the cache SHOULD validate it before
     returning it to the client.  However, not all caches will do so
     in every case.

   Because HTTP/1.0 caches ignore Cache-control directives, it might
   also be appropriate to send "Expires: <a date in the past>"
   (Example: Expires: Thu, 01 Jan 1980 00:00:00 GMT) to avoid
   improper caching.

-Jeff
Received on Wednesday, 17 April 1996 15:35:19 EDT

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