Essentially, yeah, sort of.
If a response comes back with Vary headers, then it's Big Decision
Time(tm). You can:
a) Not cache it.
b) Take each listed header field listed in the Vary and churn it's value
into the cache-key (that at least gives you a unique cache key)
Bad news:
In order to ever return a cache-hit, the proxy must be able to find out
(presumably without reconsulting the origin server) if it has an object
representation (ie: a variant or invariant) that satisfies the request.
Assumption:
If you have at least one variant stored, then you can't reliably use the
invariant version of the object (that is, any version of it that is
returned without a Vary header), since you can't predict in what ways an
object on an origin server may vary until you have a variant
representation. If you have no variants of an object stored, you
probably have to assume that the object is invariant, like most regular
objects.
More ugliness:
A request URI has to be tied to a list of cache-keys, now...not just a
single cache-key. Current processing only yields a stage-one hit. A
stage one hit tells us if we are aware of any variance in the target
URI. Then we check each of our returned keys, and decide if it can
satisfy the request. If so, that's a second-stage hit. Otherwise it's a
VARYHIT_MISS, right? That is, there are one or more variants (including
invariants) of the URI in the cache, but none of them can legitimately
satisfy the request, and the origin server must be consulted. You
_definitely_ want to cache dummy objects to tell you if a given request
generates a variant you already have (or the invariant) for that
matter...these could just be handled at the meta-data level.
Are you feeling frightened yet?
D
Adrian Chadd wrote:
> can someone with a grasp of the HTTP code verify this? I seem to
> remember it being raised on squid-dev at some time ..
>
>
> Adrian
>
> ----- Forwarded message from Patrick McManus <mcmanus@appliedtheory.com> -----
>
> Date: Wed, 15 Nov 2000 08:41:57 -0500
> From: Patrick McManus <mcmanus@appliedtheory.com>
> To: Jacob Palme <jpalme@dsv.su.se>
> Cc: wrec@cs.utk.edu, Mikael von Pfaler <mvp@borware.com>
> Subject: Re: Different web pages for different browser versions
> Reply-To: mcmanus@appliedtheory.com
> User-Agent: Mutt/1.2i
>
> this is really http, not whatever the heck wrec is (I just said that
> to get the rhyme in.), but the server should add the
>
> Vary: User-Agent
>
> header to the 1.1 response.. A 1.1 cache knows that only future
> requests with the same user-agent header (and/or any other header(s)
> listed in the vary response header) as the request that generated the
> cached response may be satisified by that cached response. (subject to
> the other normal freshness rules of course.)
>
>
>
> [Jacob Palme: Wed, Nov 15, 2000 at 11:05:00AM +0800]
>
>> I am not a regular participant of wrec. But I have a question
>> which maybe you have already solved. I tried to look into
>> your archives, but could not find it.
>>
>> The question is that more and more web sites will chech
>> which browser type the user has, and deliver different
>> versions of a web page depending on the browser type.
>>
>> How can proxies handle this, so that you deliver a cached
>> version only if it suits the browser capabilities of the
>> user?
>> --
>> Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
>> for more info see URL: http://www.dsv.su.se/jpalme/
>
>
> ----- End forwarded message -----
>
Received on Wed Nov 15 2000 - 09:31:41 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:58 MST