httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39727] - Incorrect ETag on gzip:ed content
Date Wed, 07 Jun 2006 03:57:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39727>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39727





------- Additional Comments From hno@squid-cache.org  2006-06-07 03:57 -------
>From a protocol perspective removing the ETag is sufficient to make you
compliant. If conditionals (If-xxx) anyway doesn't work right on transformed
responses there is not much benefit of sending an ETag out.

But if you can it's better if you send an ETag. As I said initially you don't
need  to compute a new etag, just adding some extra detail to the tag is fine.

I.e. "638f3e-6-1b6d6340-gzip" or similar for a gzip:ed entity where the base
entity had the etag "638f3e-6-1b6d6340".  To HTTP the etag is just a string with
the only requirement that it must be unique for each entity variants of the same
URL.

Actually I think adding details to the ETag may simplify many things for you as
the core routines then can make quick asssssments of conditionals if it's
possible to infer information about how the object had been processed from
looking at the entity tag.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message