Re: Bug #1893; why's it incomplete?

On tor, 2008-06-12 at 18:38 +0800, Adrian Chadd wrote:

> .. Which is why i think we should start a wiki page to document all
> the sorts of things we're doing ad we should be doing, to try and
> get enough information to form a "big picture" design.

Two brain cells fired and I think I now have the design for how Vary
should work. Somewhat different from today, and still one corner case to
figure out how to deal with (how to efficiently handle when Vary differs
among the variants)

The things we need to deal with, below each Vary:ing URL:

  - Entities.
  - 304 responses mapping requests to entities
  - Vary headers
  - Invalidation of everything cached for the URL

Entities are indexed by Content-Location, or ETag if no
Content-Location. If neither Content-Location or ETag then indexed by
the vary headers.

It need to be possible to query for the list of known ETag:s under an
URL.

304 responses are indexed by the vary headers.

On hits the 304 and the entity it indicates is merged to form the
response to this request.

Accept-Encoding needs a cludge as there is plenty of broken server who
when performing dynamic comression return the same object identifier
(ETag and/or Content-Location) for both the original and gzip encoded
variants, effectively splitting the URL in two (or more) depending on if
gzip is accepted or not..

Accept-* headers should be somewhat normalized to prune out silly
meaningless differencese between different client implementations,
improving hit ratio considerably.

Regards
Henrik