- 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>
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