Re: ETag & Content-Encoding

["Franklin Tse" <peaceable_whale@xxxxxxxxxxx>]

> > Should ETag be different when the content is transferred with different 
> > Content-Encoding?
>
> Yes.

Thanks!

> PS: adding a "Vary" header may make the response non-cacheable in IE, 
> which in turn will make it impossible to pass it to an external 
> application for handling. Known and reported problem for something like 5 
> years now.

The bug seems to be fixed in IE7. Thanks for the reminder.

Regards,
Franklin

--------------------------------------------------
From: "Julian Reschke" <julian.reschke@xxxxxx>
Date: Saturday, 29 September, 2007 23:38
To: "Franklin Tse" <peaceable_whale@xxxxxxxxxxx>
Cc: "atom-protocol" <atom-protocol@xxxxxxx>
Subject: Re: ETag & Content-Encoding

> Franklin Tse wrote:
> > Hi all,
> >
> > I have a question about the Entity Tag (ETag) and the Content-Encoding.
> >
> > Should ETag be different when the content is transferred with different 
> > Content-Encoding?
>
> Yes.
>
> > For example, here are the HTTP Response Headers when there is no 
> > Content-Encoding:
> >
> > HTTP/1.1 200 OK
> > X-Powered-By: PHP/5.2.4
> > ETag: "8c9329975a5e17e029312bcda6228450"
> > Cache-Control: max-age=0, must-revalidate
> > Content-Length: 2132
> > Content-Type: application/atom+xml; charset=UTF-8
> >
> > When the content is gzip-ed, which set of HTTP Response Headers is 
> > correct?
> >
> > a)
> >
> > HTTP/1.1 200 OK
> > X-Powered-By: PHP/5.2.4
> > ETag: "8c9329975a5e17e029312bcda6228450"
> > Cache-Control: max-age=0, must-revalidate
> > Vary: Accept-Encoding
> > Content-Encoding: gzip
> > Content-Length: 1091
> > Content-Type: application/atom+xml; charset=UTF-8
> >
> > HTTP/1.1 200 OK
> > X-Powered-By: PHP/5.2.4
> > ETag: "8c9329975a5e17e029312bcda6228450"
> > Cache-Control: max-age=0, must-revalidate
> > Vary: Accept-Encoding
> > Content-Encoding: deflate
> > Content-Length: 1073
> > Content-Type: application/atom+xml; charset=UTF-8
>
> These would be incorrect, because you're using the same ETag as above.
>
> > b)
> >
> > HTTP/1.1 200 OK
> > X-Powered-By: PHP/5.2.4
> > ETag: "8c9329975a5e17e029312bcda6228450;gzip"
> > Cache-Control: max-age=0, must-revalidate
> > Vary: Accept-Encoding
> > Content-Encoding: gzip
> > Content-Length: 1091
> > Content-Type: application/atom+xml; charset=UTF-8
> >
> > HTTP/1.1 200 OK
> > X-Powered-By: PHP/5.2.4
> > ETag: "8c9329975a5e17e029312bcda6228450;deflate"
> > Cache-Control: max-age=0, must-revalidate
> > Vary: Accept-Encoding
> > Content-Encoding: deflate
> > Content-Length: 1073
> > Content-Type: application/atom+xml; charset=UTF-8
>
> These would be correct.
>
> > Also, should "Vary: Accept-Encoding" be added even when there is no 
> > Content-Encoding?
>
> I would think so, but as far as I understand there are HTTP experts who 
> disagree. It depends on how you interpret RFC2616 with respect to variant 
> handling.
>
> Best regards, Julian
>
> PS: adding a "Vary" header may make the response non-cacheable in IE, 
> which in turn will make it impossible to pass it to an external 
> application for handling. Known and reported problem for something like 5 
> years now.