https://issues.apache.org/bugzilla/show_bug.cgi?id=46538
--- Comment #9 from Oliver Schoett <oliver.scho...@capgemini-sdm.com> 2009-04-17 07:59:02 PST --- Yes, sorry, the patch is indeed not sufficient. It fixes the "sending" side of the problem in that it sends out ETags that conform to the spec. However, I now understand that we also need to fix the "receiving" side of the problem, that is, deal with the ETags wet get back in If-Match, If-None-Match and If-Range header fields and make appropriate responses. This is much harder to fix, as currently the decision "can I compress or not" is made at a completely different point from the base ETag calculation, and yet we must know the set of ETags of the variants we are capable of producing to handle the If-... Requests involving ETags. Since my client needed a fix urgently (IE users behind proxy caches did receive unusable JavaScript files), I have removed ETag generation and handling completely from his production Tomcats (can supply patch if there is interest). This way, the logic for "304 Not Modified" responses relies entirely on If-Modified-Since, which works well enough if you keep the date stamps between identical copies of a resource on different servers of a farm in sync. -- BTW, the part of RFC2616 that makes it most clear that ETags are per variant is in Section 13.6; for example: If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. This algorithm makes no sense unless ETags are per variant. Unfortunately, the section that defines ETags (14.19) says nothing about this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
