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
signature.asc
Description: This is a digitally signed message part
