William A. Rowe, Jr. wrote: > Just a quick tangent on weak ETags.... > > let's say I have a transform to convert (charset-any) into utf-8 format... > and based on a browser string, conditionally insert that filter. > > It's a straightforward (predictable) transform so that it retains any strong > ETag, but it isn't the identity. Wouldn't it make more sense to concat > a suffix onto the existing ETag?
keeping an already existing (strong) ETag (such as one generated by default_handler) seems suspect to me. because the response now involves content altering logic, there is the chance that a bug in the logic could render the response bits different before and after bug discovery. if the ETag ends up being the same (even weakened) it seems like it would be wrong. so, adding to or otherwise predictably altering the previously generated ETag seems to make sense (to me :), so long as it takes into account code versions or whatever else effects the response translation (config directives or whatnot). the criterion that makes me most nervous when I play with ETags is the requirement that "An entity tag MUST be unique across all versions of all entities associated with a particular resource" which feels very difficult to get right if you're not in control of the entire tag. fwiw, the need for the ap_weaken_etag API I was suggesting stemmed from simple HTML scrubbing, such as changing <strong> to <b>. it's probably rare that people will want or need to use it, but it will be nice to have if they need it. --Geoff
