httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordström <hen...@henriknordstrom.net>
Subject Re: thoughts on ETags and mod_dav
Date Sun, 30 Dec 2007 05:52:14 GMT
lör 2007-12-29 klockan 15:09 -0800 skrev Chris Darroch:
>    Reading that over, it still makes some sense to me.  Apache httpd is
> never in the situation implied by the RFC's example, where one wants to
> generate a weak ETag because one has knowledge that the file's semantic
> meaning hasn't changed, and therefore one can use the file's mtime to
> generate the weak ETag.

True, you don't know. Just as you don't really know there hasn't been
any direct fs modifications where the mtime was not updated.

In the end this boils down to a probability weighted design decision.
Not sending ETag (even a weak one) is bad for caching and WebDAV. Not
updating the ETag on changes (semantic changes in case of weak) is also
bad for caching and WebDAV. So you have to select which badness is the
worst unless you can generate real strong ETags using a versioned store
or similar.

ETag is not a "last-modified". It's a unique identifier identifying the
variant representation. It needs to change each time the representation
changes, but it's perfectly fine that it returns back to the same value
if the representation does even if the modification time is not the
same, or that it does not change if the only change is the last-modified
timestamp.

>    Currently, when httpd notices that a file's mtime and the current
> time are the same, ap_make_etag() just creates its usual ETag but
> then marks it as weak.  This has the advantage of being fast, since,
> as you point out, high performance is critical.  If I understand
> the issues at hand correctly, though, to resolve #42987 we should
> really just not generate any ETag at all in this case.

Not generating an ETag on objects modified "now" will bring a number of
other cache issues, mainly on negotiated objects (Vary responses).

> I'd proposed putting this into the hands of the administrator
> via a configuration directive:

As long as it's properly explained why one should not change the setting
without knowing the implications I am fine.

>    Does that seem out to lunch?  Certainly the intention is not
> to run counter to the RFC, but rather to do the best job of
> conforming to it while providing high performance, and being backwards-
> compatible with existing behaviour where that's appropriate.

I like the none/weak/ignore proposal even if I would use
none/weak/strong. Things done weirdly is best left configurable as
different setups have different tradeoffs, and one size fits all
solutions always have exceptions when it doesn't fit..

Regards
Henrik

Mime
View raw message