W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

Re: weak entity tags vs Apache moddav

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
Message-ID: <Pine.BSF.4.44.0211140852130.37760-100000@measurement-factory.com>

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.



                            | 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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC