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

Bil Corry wrote:

> For web applications with dynamic content, it is easier to just
> prevent caching than it is to implement a system to handle
> If-Modified-Since.  Expires header isn't an option when the content
> can change at any given moment.

I use Etags.  The ETags are generated from all the prerequisites to
the dynamic content as accurately as possible.  E.g. a combined result
of all the file timestamps and sizes which are used to make the
content, and database cache tags.

I agree that it's not entirely easy, although good frameworks usually
have a way to encapsulate it.

> Of course, that's for HTML content; for media assets (png, jpg,
> etc), we use the Expires header to prevent any further requests for it.

I do similar.

For dynamically generated images, I set Expires 1 year into the
future, and use a hash of the image, either of the image file itself
or the instructions used to generate it, and use the hash as part of
the URL of the image.  That way it can be dynamic but only fetched
when it changes, by the HTML which references it changing automatically.

It's a bit complicated, but it can be hidden well in the guts of a
server and performs well.

> That's the reason you see the shotgun approach to preventing
> caching; different browsers (and legacy browsers) and proxies respond
> to different headers.  And even then, I still hear about users behind
> a corporate proxy that serves cached content from one to another,
> causing User A to see User B's information.
>
> Is there a resource that gives the "official" way to prevent caching
> across all browsers and proxies?

I don't think there is any "official" method which considers all real
implementations.  Official and implementation are in constant tension.

As your example shows, there might not be any way.
Some ancient caches just have a fixed expiry age configured.

The ultimate method is to keep changing the URL.
(Similar to the way some frameworks change the names of form elements,
to prevent browsers from pre-filling forms with wrong sensitive data by
accident).

This is what I've found, for the paranoid:

    Pragma: no-cache
    Cache-Control: no-cache,max-age=0,must-revalidate,pre-check=0,post-check=0
    Expires: VERY-OLD-DATE

The apparently redundant fields are in case of implementations which
don't understand, or don't correctly implement, the other fields.

There's probably a browser out there which doesn't understand
"Cache-Control: no-cache,..." when there's anything else on the same
line.  IE had a reputation for being a bit rigid in how it recognises
some headers.  But I'm pretty sure anything like that will recognise
"Pragma: no-cache" so it doesn't matter.

-- Jamie

Received on Thursday, 25 June 2009 00:47:30 UTC