Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Subject: Re: Wrong etag sent with mod_deflate
From: Henrik Nordstrom <henrik@henriknordstrom.net>
To: dev@httpd.apache.org
In-Reply-To: <5c902b9e0612061742g7c92923ci9e65d6a4e274dc3f@mail.gmail.com>
References: <200612061412.kB6ECwB10034@devsys.jaguNET.com>
	 <cc67648e0612060620p4980c023l5b71a1d733fa59bd@mail.gmail.com>
	 <5c902b9e0612060631r22142de1hab6b2c0e5c0d70e6@mail.gmail.com>
	 <cc67648e0612060638j15e6dde6sb8a96d1d788ad84c@mail.gmail.com>
	 <1165440698.25682.84.camel@henriknordstrom.net>
	 <2B0946B4-384C-447C-B19A-9907D4B7CB00@gbiv.com>
	 <5c902b9e0612061731m455764f3u36ca04e34c2345e9@mail.gmail.com>
	 <5c902b9e0612061742g7c92923ci9e65d6a4e274dc3f@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-eoE6cnjMG8z/V7JGzMUp"
Date: Thu, 07 Dec 2006 23:45:59 +0100
Message-Id: <1165531559.25753.27.camel@henriknordstrom.net>
Mime-Version: 1.0


--=-eoE6cnjMG8z/V7JGzMUp
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:

> -1 on adding semantic junk to the existing ETag (and keeping it
> strong); that's blatantly uncool.  Any generated ETag from mod_deflate
> should either be the original strong version or a weak version of any
> previous etag.  mod_deflate by *definition* is just creating a weak
> version of the prior entity.

You basically only have two choices:

a) Make mod_deflate not send an ETag on modified responses.

b) Modify the value (within the quotes) of the ETag somehow. And if
mod_deflate can not be trusted to always return the same octet
representation make sure to use an weak ETag unless the ETag generation
is also tightly coupled to the octet representation guaranteing a
different ETag should mod_deflate encode slightly different.

And to be fully compliant you also need to pay attention to the
Content-Location header. Here I don't see much choice but to not send
Content-Location in mod_deflate mangled responses (but can be kept on
the original response, no problem there).

RFC 2616 13.6 Caching Negotiated Responses, last paragraph.

> mod_deflate does properly stick in the Vary header, so caches already
> have enough knowledge to know what's going on anyway even without a
> fix.  (This is probably why mod_cache doesn't flag it as an error.)

> My opinion is to fix the protocol and move on...  -- justin

The protocol is quite fine as it is, and not easy to change. As it is
now it's mainly a matter of understanding that mod_deflate does create a
completely new entity from the original one. To the protocol it's
exactly the same as when using mod_negotiate and having both the
identity and gzip encoded entities on disk. The fact that you do this
encoding on the fly is of no concern to HTTP.

Another option is to explore the use gzip transfer encoding instead of
content encodin. In transfer encoding none of these problems apply as
it's done on the transport level and not entity level, but it's not that
well supported in clients unfortunately..

Regards
Henrik

--=-eoE6cnjMG8z/V7JGzMUp
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.5 (GNU/Linux)

iQCVAwUARXiZpENPQ5Kbx8daAQI1ZQP8Cg+g820c/8VgS71iR2o33FGSc4wqFNiV
BI0/IPkIEllTuKbeUfrp/7M8l50VrjoHB4BiNsoW5/+RoacbOqjvbCK+EOHz2jqt
Cq4SMQQfVqxAjZcrx2HLmFhgVs/F0XYuHR6RsvPbvlmeF1+2pcWoF80FxODegz2W
WAhz5Yy4GwE=
=jfMJ
-----END PGP SIGNATURE-----

--=-eoE6cnjMG8z/V7JGzMUp--