[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.