Creating strong Etags would be not to difficult, if the WebDAV
repository is only changed by mod_dav. To me it seems not very
important, how exactly the strong Etag is created:
(filesize+inode+counter, counter only, locking the file for one second,
enforcing an inode-change. All this can work. Even delaying some
PUT-requests (because of locking) would not be a problem, as it would
occur rarely.
But the problem is, that mod_dav might be bypassed. There are just two
possible solutions:
1) make sure, mod_dav can reliable detect any changes by what ever means
they are made
2) put the responsibility on the administrator.
As I cannot see any realistic solution according 1), I propose solution
2). The suggested check for changes made outside of mod_dav is only
meant to catch *most* of the errors made by administrators. It cannot be
reliable, and is not meant to take the responsibility from the
administrator.
A configuration option should allow the administrator to deny his/her
responsibility. Doing so, the WebDav-server can no longer create strong
Etags it will get inefficient and unreliable. But this would at least be
the responsibility of the administrator. The documentation has to be
very clear about this.
Concerning Etags outside of WebDAV:
Henrik Nordström wrote:
> ..., and the weak ETag may be useful to
> intermediaries which implements local If-None-Match processing so
> sending a weak etag is actually better than none, especially so if the
> object Vary:es..
I have no idea what this would be. Can you give a *short* outline?
Please note: The weak Etags generated by Apache will *never* match. So
the only way I see, how Apache's weak Etags could be used, is to ignore
the weakness indicator, as I do in davfs2. But this is of course not how
weak Etags are meant to work and includes some risk.
So I still think: Apache's weak Etags are *none*-Etags and simply imply
no-cache. It would be better to say this in the clear.
BTW: IIS seems to do the same, but this doesn't make it better.
Werner
