Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: ETag and Content-Encoding
From: Henrik Nordstrom <henrik@henriknordstrom.net>
To: dev@httpd.apache.org
Cc: Nick Kew <nick@webthing.com>, feil@productandconcept.com,
        julian.reschke@gmx.de
In-Reply-To: <5c902b9e0710030753j1346a27blb6fd1afac4cc2df0@mail.gmail.com>
References: <20071003142304.7e7228b8@grimnir>
	 <1191421201.25254.18.camel@henriknordstrom.net>
	 <5c902b9e0710030753j1346a27blb6fd1afac4cc2df0@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-fMxuMIGyhx3S4Tbo/fSd"
Date: Wed, 03 Oct 2007 23:27:45 +0200
Message-Id: <1191446865.25254.46.camel@henriknordstrom.net>
Mime-Version: 1.0


--=-fMxuMIGyhx3S4Tbo/fSd
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On ons, 2007-10-03 at 07:53 -0700, Justin Erenkrantz wrote:

> As before, I still don't understand why Vary is not sufficient to
> allow real-world clients to differentiate here.  If Squid is ignoring
> Vary, then it does so at its own peril - regardless of ETags.

See RFC2616 13.6 Caching Negotiated Responses and you should understand
why returing an unique ETag on each variant is very important. (yes, the
gzip and identity content-encoded responses is two different variants of
the same resource, see earlier discussions if you don't agree on that).

But yes, thinking over this a second time converting the ETag to a weak
ETag is sufficient to plaster over the problem assuming the original
ETag is a strong one. Not because it's correct from a protocol
perspective, but becase Apache do not use the weak compare function when
processing If-None-Match so in Apache's world changing a strong ETag to
a weak one is about the same as assigning a new ETag.

However, if the original ETag is already weak then the problem remains
exactly as it is today..

Also it's also almost the same as deleting the ETag as you also destroy
If-None-Match processing of filtered responses, which also is why it
works..

> The problem with trying to invent new ETags is that we'll almost
> certainly break conditional requests and I find that a total
> non-starter.

Only because your processing of conditional requests is broken. See
earlier discussions on the topic of this bug already covering this
aspect.

To work proper the conditionals needs to (logically) be processed when
the response entity is known, this is after mod_deflate (or another
filter) does it's dance to transform the response headers. Doing
conditionals before the actual response headers is known is very
errorprone and likely to cause false matches as you don't know this is
the response which will be sent to the requestor.

> Your suggestion of appending ";gzip" leaks information
> that doesn't belong in the ETag - as it is quite possible for that to
> appear in a valid ETag from another source - for example, it is
> trivial to make Subversion generate ETags containing that at the end -
> this would create nasty false positives and corrupt Subversion's
> conditional request checks.

Then use something stronger, less likely to be seen in the original
etag. Or fix the filter architecture to deal with conditionals proper
making this question ("collisions") pretty much a non-issue.

Or until conditionals can be processed correctly in precense of filters
drop the ETag on filtered responses where the filter do some kind of
negotiation.

> Plus, rewriting every filter to append or
> delete a 'special' marker in the ETag is bound to make the situation
> way worse.  -- justin

I don't see much choice if you want to comply with the RFC requirements.
The other choice is to drop the ETag header on such responses, which
also is not a nice thing but at least complying with the specifications
making it better than sending out the same ETag on incompatible
responses from the same resource.

Regards
Henrik

--=-fMxuMIGyhx3S4Tbo/fSd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iQCVAwUARwQJTkNPQ5Kbx8daAQJs0QQAzDiPYlzxgavvMHMHVUodJrPSQampEsOs
rvf65Pl+enFsXTOpZmYX3oeWztelEiA6lPrqc5sNbk2+N/SnpQtxoa7xpgyciURL
VeHB+0INXnNmBkh3oD8mv319WX3pM/kw9BRWkGHUBDE2VHh6mgw9TBzdqW9VH2Cy
IgAWy0G+1A4=
=1MVN
-----END PGP SIGNATURE-----

--=-fMxuMIGyhx3S4Tbo/fSd--