Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of hno@squid-cache.org designates
 12.160.37.9 as permitted sender)
Subject: Re: Wrong etag sent with mod_deflate
From: Henrik Nordstrom <hno@squid-cache.org>
To: dev@httpd.apache.org
In-Reply-To: <45800545.4040404@turner.com>
References: <200612061412.kB6ECwB10034@devsys.jaguNET.com>
	 <1165531559.25753.27.camel@henriknordstrom.net>
	 <958C9371-4A20-4765-BC90-5DD63301269A@gbiv.com>
	 <5c902b9e0612081535n5dd4302ek7afdae87933b55e6@mail.gmail.com>
	 <B2A9B2B3-D938-4C7D-8434-B9FC00A120D3@gbiv.com>
	 <457A9F3A.4090900@apache.org>
	 <5c902b9e0612090623g3625007dle99822aa8552ca06@mail.gmail.com>
	 <38B6949E-DE72-49B1-8EED-8FB8E740E712@gbiv.com>
	 <457BF4A8.4020508@apache.org> <457BFDFF.80408@apache.org>
	 <5c902b9e0612100736ib39aaf1h236c608197e9f81@mail.gmail.com>
	 <457C2F3F.2060006@apache.org>
	 <1165767254.11775.62.camel@henriknordstrom.net>
	 <457DB08F.1040606@turner.com>
	 <1165875737.14973.18.camel@henriknordstrom.net>
	 <457EBACB.3030309@turner.com>
	 <1165976469.3890.16.camel@henriknordstrom.net>
	 <45800545.4040404@turner.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-ucorX4ZPOnv+kkmIkmJ9"
Date: Thu, 14 Dec 2006 00:24:31 +0100
Message-Id: <1166052271.3890.51.camel@henriknordstrom.net>
Mime-Version: 1.0


--=-ucorX4ZPOnv+kkmIkmJ9
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

ons 2006-12-13 klockan 08:51 -0500 skrev Brian Akins:

> However, on an initial request (ie, non-conditional) we do not have an et=
ag from=20
> the client, we only have info like Host, URI, Accept-*, etc.  So, how wou=
ld the=20
> cache identify which entity to serve in this case?

You have the URL and the "other" cached entities of that URL. It does
not matter if the client request was a conditional or not. The
conditions in the request is on the response to see if it should be a
200 or 304, not selectors on what entity to respond with. The selected
response entity is always the same for the same request, with or without
conditions.

Obviously on the very first request for a given URL you have nothing,
and that request is forwarded without any added condition. However,
after that every Vary cache miss on that URL is a If-None-Match
conditional to ask the server if any of the cached entity variants is
applicable for the current request.

> I have read it many times.. In our case - cnn.com, etc. - we have to deci=
ded to=20
> be RFC "compliant" from the client to the cache server.  From the cache t=
o the=20
> origin, however, we are not as concerned.

And you are free to. A reverse proxy is by definition the origin server.
How it finds the content is of no concern to the RFC, just happens to be
HTTP and not plain files, NFS, database or whatever.

> In a reverse-proxy-cache, this is not=20
> a big deal. However, in a "normal forward-proxy-cache," where one does no=
t=20
> control both cache and origin, one must be more careful.

Indeed.

But on the other hand it's actually reverse proxy configurations which
has pushed for 13.6 compliance in Squid as it's a lot easier for
processing intensive servers to evaluate If-None-Match than to render
the entity again, and when you depend on Accept-Language +
Accept-Encoding + User-Agent the number of request combinations becomes
quite significant, especially if there maybe only is two or three
variants under the URL.

Regards
Henrik

--=-ucorX4ZPOnv+kkmIkmJ9
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad
	meddelandedel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQCVAwUARYCLq0NPQ5Kbx8daAQLpRgP+OxJCMpQpMm9fKk9C4S9EfF8ILVRPt7Cw
GpbszpwOvMFeHhOZ/fCplf2tCItS2BSvsZGgxZEbj/Gl4uHxR8++ylXRv2/kHX/v
pqh1BG6cxOU4SYdKh0mnbp3s4ZyQZ84zYKKfGe65F41vowQMbWbDYbRvpJUgPGWH
KXJYf83nnbI=
=H6ky
-----END PGP SIGNATURE-----

--=-ucorX4ZPOnv+kkmIkmJ9--