- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Thu, 14 Nov 2002 09:09:27 -0700 (MST)
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: ietf-http-wg@w3.org
On Thu, 14 Nov 2002, Julian Reschke wrote: > In section 3.11 [1], RFC2616 states: > > "A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two > entities of a resource only if the entities are equivalent and could be > substituted for each other with no significant change in semantics. A weak > entity tag can only be used for weak comparison." > > Apache moddav indeed returns weak entity tags based on a filesystem > timestamp. However, as far as I understand there's no guarantee whatsoever > that two entities written within one second indeed can "be substituted for > each other with no significant change in semantics". So is this a bug or am > I missing something important? I guess you can call it a violation of the section 3.11 requirement. Whether that violation is a bug depends on what Apache authors intended to implement. I bet the code works as they intended. Webdav does not know about semantics so, ideally, it needs to generate strong tags. However, there is a trade-off between code simplicity and tag strength and it seems like Apache folks resolved this trade-off by declaring a simple-to-implement tag "weak". I do not know whether they knew about the requirement you cite; you may want to check source code for insightful comments. Please note that HTTP is designed in such a way that the above violation is unlikely to cause problems with compliant implementations because weak tag comparison is not used for potentially "dangerous" operations such as merging of ranged responses. In other words, under normal conditions, Apache users will not suffer from the deficiencies of the code, provided webdav explicitly marks the tag as weak. One can always come up with a corner case, of course. If the Web site owner does not think that one second precision is good enough, it should be relatively simple to patch the code to generate strong tags instead (e.g., by appending a sufficiently long and sufficiently random number to the timestamp). Using MD5 checksums would be even better, but also more expensive. This is my interpretation of the situation. I am neither an RFC editor nor Apache developer. HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance
Received on Thursday, 14 November 2002 11:09:38 UTC