ons 2013-07-24 klockan 18:46 -0600 skrev Alex Rousskov:
>
> > The full logics (still missing from squid-3) involves an n-m map of
> > requests to response variants.
>
> I thought Squid already tries to support that. Or are you talking about
> responses with varying Vary header values (discussed further below)?
Squid-2 does, but Squid-3 only keeps a 1-1 map.
> > This has direct impact on where Vary logics can be performed.
>
> Can you elaborate on this point? I think there are ways to support full
> Vary logics with and without "all variants are in one store" restrictions.
It has an impact on how many store api accesses is needed to resolve a
request for a varying URL.
> > * Add mapping of request headers to specific response variant
> > (identified by ETag).
>
> AFAIK, this is already supported by adjusting the store key.
No, there is no way to query the store which ETags are known for a URL.
All it knows is that the URL response varies.
> > * Lookup the response matching this specific request.
>
> This is already supported by looking up the computed key in the store index.
Sort of. That lookup is today based on URL + response headers which is
correct for objects with no ETag.
> > To complicate matters further different responses MAY have different
> > Vary header value. But it is not very likely.
>
> True. To support that, we would need to add a list of Vary header values
> to the special Vary object and iterate it, looking up a cache object for
> every listed Vary header value.
It's a little more complicated than that.
> > 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 don't think it's separate. It has direct impact on how you can store
responses to a varying URL and how to handle cache validation.
Regards
Henrik
Received on Thu Jul 25 2013 - 06:33:19 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 25 2013 - 12:00:11 MDT