BTW, an entity tag does not identify the entity -- it merely acts as a key for cache and range request handling.
right. and what I was trying to do was make it possible for
content-altering filters to handle that key a bit more intelligently than
just removing it altogether. the situation I initially had in mind was when
a filter was bitwise altering the content but not the semantics of it, an
HTML scrubber perhaps. in this case, it seems that allowing the default
ETag is wrong, but that removing it can be avoided (thus keeping to the
spirit that ETags should be sent if feasable). granted, the circumstances
are probably very rare that filters would behave that way. are you saying
that weakening the ETag is the wrong behavior here? if so I'm kinda wasting
my time (as well as everyone else's).
If the filter is tied to the URI such that every GET request on that URI will invoke the filter, then there is no reason to weaken the tag (and many reasons why you wouldn't want to). If, however, the filter is only sometimes invoked, then the filter should define its own strong entity tag based on the original etag. Basically, the only time a weak entity tag should be produced is if the server is unsure about the content actually reflecting the conditions evaluated in creating the ETag itself (like last-modification dates that indicate the content may have changed during the request).
If a filter
consistently produces the same content, then it should not modify the
entity tag (the routine that arranges the filters must do that if needed).
hmm... I don't see how that would work given the current API. but it does
seem like the API could be a bit better. perhaps filters could supply
criteria that ap_make_etag can draw from when the time comes. is that what
you had in mind?
I don't know. My original criticism of the API still holds true: a filter
cannot process the metadata separately from the data -- the metadata must
flow through the same filter chain rather than be operated upon as if
it were global variables. Nobody has taken up that suggestion, and I
haven't had time to implement it myself.
....Roy
