httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <hen...@henriknordstrom.net>
Subject Re: thoughts on ETags and mod_dav
Date Tue, 16 Oct 2007 12:49:15 GMT
On tis, 2007-10-16 at 11:33 +0100, Nick Kew wrote:

> For example, Henrik Nordstrom suggests ";gzip".  If we expand that to,
> say, ";CE=gzip", then we can start to apply semantics to decoding the
> Etag, and determine equivalence.  So in that case, we could determine
> that the (uncompressed) file does indeed match the ETag.  Not sure if
> there's anything we might do with other negotiated headers, but maybe
> we could leave that open, providing a hook that something like
> mod_negotiation might someday use.

It's not immediately relevant to mod_negotiation, mainly to filters
doing negotiated transformation of responses where the original response
has an ETag. mod_deflate is the most apparent and most frequently used
such filter, but I can think of many other such as dynamic image
conversion (png->jpg for user-agents not handling png, lowres for small
devices etc.) etc.

Having some structure on the tokens is helpful, but not strictly needed
as long as each step in the filter chain can recognise it's token and
add/remove it as needed.

Add token to ETag when the response goes out, reflecting the negotiation
process done by the filter. As discussed earlier a token may need to be
always added to avoid conflicts with other ETag sources possibly
generating ETag values with the same token format.

remove from If-* when processing requests and conditions still match for
the step in question. If conditions no longer match the token then the
condition needs to be rejected.

Having a clear structure may allow you to make efficient shortcuts in
the processing, but probably only when the resource has changed making
the original resource ETag different.


Hmm.. looking at mod_negotiate again it may be relevant there as well
when using the body typemap feature. Today mod_negotiate do not return
an ETag under such conditions, but using tokens it could, allowing for
proper cache validation of body typemap negotiated resources. Using
tokens is in fact not very different from what mod_negotiate does today
chaining the etags of the typemap and the selected variant.

The token idea is however not relevant to mod_negotiate multiviews as
the selected variant already has an unique ETag and is sufficient
identification of the selected variant. No need to complicate that quite
common case.

Regards
Henrik

Mime
View raw message