W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: httpbis-p6-cache-06 and no-store response directive

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 25 Jun 2009 03:51:17 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: Bil Corry <bil@corry.biz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <1245894677.24869.24.camel@localhost.localdomain>
tor 2009-06-25 klockan 01:17 +0100 skrev Jamie Lokier:
> > RFC2616?
> No, because it does not cover all browsers and proxies.
> Only those conforming to RFC2616.
> It probably doesn't even cover most proxies.  When did Squid get
> HTTP/1.1 support?

It hasn't even come there yet (almost there now). But has understood
Cache-Control since about a decade or so...

> If the Expires is older than Date, I see why the proxy can't cache,
> but why do think it permits caching in browsers?

Expires older than Date has nothing to do with browser vs proxy. Just
HTTP/1.0 vs 1.1.  It's a safety precaution if you should ever encounter
a HTTP/1.0 client cache (user-agent or proxy) who don't know about

For anything reasonably modern Cache-Control max-age takes priority over

> Is the common advice to include "Pragma: no-cache" unnecessary?

These days yes. And was in fact never really needed provided you expired
the content...

> There's also the Microsoft ones, post-check and pre-check:
> The post-check and pre-check cache-control extensions are defined as follows:
>     * post-check
>         o Defines an interval in seconds after which an entity must be
>           checked for freshness. The check may happen after the user
>           is shown the resource but ensures that on the next roundtrip
>           the cached copy will be up-to-date.
>     * pre-check
>           o Defines an interval in seconds after which an entity must
>           be checked for freshness prior to showing the user the
>           resource.

Sounds similar to some other cache-control headers proposed by mnot some
year ago..

> I'm not quite sure how these differ from max-age, but they presumably do.

post-check is about adding a bit of fuzziness to the process, doing
cache validation asynchronous from client request, showing the client
the cached copy while performing a cache validation in the background.

but I don't get how pre-check differs from max-age...

> Some advice on disabling caching includes these.

I think that's just "because they exists in MSIE so we better set them
to something..." but I don't know. Haven't studied MSIE handling of

Received on Thursday, 25 June 2009 01:52:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:40 UTC