Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: TOKILEY@aol.com
Message-ID: <7a.5dcdc031.2e42ad0d@aol.com>
Date: Wed, 4 Aug 2004 17:20:13 EDT
Subject: Re: [PATCH] mod_disk cached fixed
To: dev@httpd.apache.org
CC: TOKILEY@aol.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="part1_7a.5dcdc031.2e42ad0d_boundary"


--part1_7a.5dcdc031.2e42ad0d_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


> Brian Akins wrote...
>
> Serving cached content:
>
> - lookup uri in cache (via md5?).
> - check varies - a list of headers to vary on
> - caculate new key (md5) based on uri and clients value of these headers
> - lookup new uri in cache
> - continue as normal

Don't forget that you can't just 'MD5' a header from one response and
compare it to an 'MD5' value for same header field from another response.

A "Vary:" check does not mean 'has to be exactly the same as the other one'.

It just has to be 'semantically' different.

You can have a header value that is formatted differently from another
and it is still, essentially, the SAME as another and does NOT VARY.

That includes different amounts of whitespace and a different
'ordering' of the 'values'. As long as the 'values' are the SAME
with regards to another header, then the header fields do
NOT VARY.

The only way to do it right is to be able to parse each and every
header (correctly) according o BNC and and compare them 
that way. Syntax or whitespace differences don't automatically
mean a header 'Varies' at all.

> The thing that sucks is if you vary on User-Agent.  You wind up with a 
> ton of entries per uri.  

Yep. That's how 'Muli-Variants' works. There might be very good
reasons why every 'Varying' User-Agent needs a different 'Variant'
of the same response.

> I cheated in another modules by "varying" on an 
> environmental variable.  Kind of like this:
>
> BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip
>
> and just "vary" on no-gzip (1 or 0), but this may be hard to do just 
> using headers...

It's not hard to do at all... question would be whether it's ever
the 'right' thing to do.

The actual compressed content for different 'User-Agents' might
actually 'Vary:' as well so no one single compressed version of
a response should be used to satisfy all non-no-gzip requests
if there is actually a 'Vary: User-Agent' rule involved.

It's pretty hard to 'cheat' on 'Vary:'

That's why it remains one of the least-supported features of HTTP.

It's kind of an 'all or nothing' deal whereby if you can't do it ALL
correctly... then might as well do what most products do and
treat ANY 'Vary:' header as if it was 'Vary: *'  ( Vary: STAR )
and don't even bother trying to cache it.

Kevin Kiley


--part1_7a.5dcdc031.2e42ad0d_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10><BR>
&gt; Brian Akins wrote...<BR>
&gt;<BR>
&gt; Serving cached content:<BR>
&gt;<BR>
&gt; - lookup uri in cache (via md5?).<BR>
&gt; - check varies - a list of headers to vary on<BR>
&gt; - caculate new key (md5) based on uri and clients value of these header=
s<BR>
&gt; - lookup new uri in cache<BR>
&gt; - continue as normal<BR>
<BR>
Don't forget that you can't just 'MD5' a header from one response and<BR>
compare it to an 'MD5' value for same header field from another response.<BR=
>
<BR>
A "Vary:" check does not mean 'has to be exactly the same as the other one'.=
<BR>
<BR>
It just has to be 'semantically' different.<BR>
<BR>
You can have a header value that is formatted differently from another<BR>
and it is still, essentially, the SAME as another and does NOT VARY.<BR>
<BR>
That includes different amounts of whitespace and a different<BR>
'ordering' of the 'values'. As long as the 'values' are the SAME<BR>
with regards to another header, then the header fields do<BR>
NOT VARY.<BR>
<BR>
The only way to do it right is to be able to parse each and every<BR>
header (correctly) according o BNC and and compare them <BR>
that way. Syntax or whitespace differences don't automatically<BR>
mean a header 'Varies' at all.<BR>
<BR>
&gt; The thing that sucks is if you vary on User-Agent.&nbsp; You wind up wi=
th a <BR>
&gt; ton of entries per uri.&nbsp; <BR>
<BR>
Yep. That's how 'Muli-Variants' works. There might be very good<BR>
reasons why every 'Varying' User-Agent needs a different 'Variant'<BR>
of the same response.<BR>
<BR>
&gt; I cheated in another modules by "varying" on an <BR>
&gt; environmental variable.&nbsp; Kind of like this:<BR>
&gt;<BR>
&gt; BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gz=
ip<BR>
&gt;<BR>
&gt; and just "vary" on no-gzip (1 or 0), but this may be hard to do just <B=
R>
&gt; using headers...<BR>
<BR>
It's not hard to do at all... question would be whether it's ever<BR>
the 'right' thing to do.<BR>
<BR>
The actual compressed content for different 'User-Agents' might<BR>
actually 'Vary:' as well so no one single compressed version of<BR>
a response should be used to satisfy all non-no-gzip requests<BR>
if there is actually a 'Vary: User-Agent' rule involved.<BR>
<BR>
It's pretty hard to 'cheat' on 'Vary:'<BR>
<BR>
That's why it remains one of the least-supported features of HTTP.<BR>
<BR>
It's kind of an 'all or nothing' deal whereby if you can't do it ALL<BR>
correctly... then might as well do what most products do and<BR>
treat ANY 'Vary:' header as if it was 'Vary: *'&nbsp; ( Vary: STAR )<BR>
and don't even bother trying to cache it.<BR>
<BR>
Kevin Kiley<BR>
<BR>
<BR>
</FONT></HTML>
--part1_7a.5dcdc031.2e42ad0d_boundary--