httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Baumann <werner.baum...@onlinehome.de>
Subject Re: thoughts on ETags and mod_dav
Date Sat, 29 Dec 2007 09:42:08 GMT
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



Mime
View raw message