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: Jamie Lokier <jamie@shareable.org>
Date: Wed, 24 Jun 2009 21:47:09 +0100
To: Yngve Nysaeter Pettersen <yngve@opera.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20090624204709.GY14121@shareable.org>
Yngve Nysaeter Pettersen wrote:
> On Mon, 08 Jun 2009 04:09:16 +0200, Mark Nottingham <mnot@mnot.net> wrote:
> >I think the your question should be posed as: what compromises the cache  
> >subsystem?
> >
> >In a browser, the HTML parser component would dispatch requests to a  
> >cache, which then either satisfies the requests or forwards them. If an  
> >HTML page has three references to <http://example.com/foo.gif>, for  
> >example, there are two ways of approaching this problem;
> >
> >1) asking the cache for foo.gif once (perhaps by piggybacking the  
> >callbacks for subsequent images into the first instance), or
> >
> >2) asking the cache for foo.gif three times.
> Mark, from my point of view, the document parsing code have to do #2  
> before it can do #1, as #2 produces the index key used by #1.

I think #1 is fine, and it's what I'd expect any good browser to do.

Furthermore, if a page creates Image objects (e.g. for rollovers),
then I'd expect the browser to fetch/revalidate them exactly once, not
every time the image is displayed as some versions of IE did.

An "index key" is just an implementation detail which has nothing to
do with HTTP.  My server-side dependency-structured caches don't use
an index key, for example.

It's not _that_ hard to implement #1, even if you do it by asking the
cache for foo.gif three times like #2.  As an internal implementation
detail, you can associate the internal cache request with the
displayed page which is making it, so piggybacking them like #1.

-- Jamie
Received on Wednesday, 24 June 2009 20:47:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC