Re: What is The logic of Vary Headers cachiness?

tor 2013-07-25 klockan 17:23 +1200 skrev Amos Jeffries:

> We think alike. See my other reply. Although the lookup per-match is not
> required. HTTP only requires that we identify a whole set of options and
> pull the most appropriate - with some requirements around defining
> "appropriate".

newest match is hightly preferable.

> >> Or better yet allow the same response body to be
> >> referenced by multiple responses (simplifies validation logics and aging
> >> considerably). Response headers is the original response updated with
> >> header data from the 304 response in response to If-None-Match.
> > It feels like this is kind of separate optimization. It can be
> > restricted to Vary transactions, but does not have to be.
>
> I agree. It is not clear which cases of Vary handling this would be
> appropriate for. We do however need to fix bug #7 once and for all.

The map used in squid-2 do not really work well in cache validations.
The problem is that the full objects gets revalidated when we get a new
304 response, when actually it's only the response that matches this
request that have been revalidated.

There is also a problem with too much churn in the x-vary marker object.

Regards
Henrik
Received on Thu Jul 25 2013 - 06:38:22 MDT