httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Clark <mich...@metaparadigm.com>
Subject Re: thoughts on ETags and mod_dav
Date Sat, 29 Dec 2007 05:19:06 GMT
Henrik Nordström wrote:
> Modifications made using direct filesystem access, in the same second as
> the last WebDAV update and only rewriting the file in-place without
> changing the length.
>   

That would be a reasonable limitation - hence the suggesion for a 
DavETagIsolation dav-only (the default being a more conservative dav+fs)

>> A correct implementation would have to regenerate the strong ETag for 
>> all of these sub second occurring requests (which is counter intuitive 
>> for a cached property and also very inefficient).
>>     
>
> No, but if direct filesystem access is allowed it would need to be able
> to detect that there has been a such access in the same second and
> invalidate the strong ETag.
>   

AFAICT, we are in agreement here. My point was related to the current 
inability to detect the direct filesystem access i.e. with the 
DavETagIsolation dav+fs you would have to invalidate the ETag unless you 
had some sort of  mechanism to detect sub second direct filesystem 
accesses (or mandatory locking as you propose) - i.e. invalidate strong 
ETag == regenerate strong ETag.

Assuming direct filesystem access is not allowed then a stored ETag with 
mtime+inode+length+modification counter would be guaranteed to be enough 
(yes, it would need to be stored due to the additional counter) as 
mod_dav would be the only one changing anything.

Alternatively, a PUT without Content-Range (the common case) could be 
changed to mktemp / open / write / close / rename - this may remove the 
need for storing anything as a normal PUT would always change the inode 
(it would catch most of the common cases - excluding direct filesystem 
modification within the same second or mmap changes which don't update 
mtime and PUT with Content-Range which I think is a pretty special case?).

>> The other proposals I've been reading seem to require saying that this 
>> ETag is strong when we know that this it not guaranteed to be true - but 
>> perhaps this should be up to the admin (DavETagIsolation dav-mods-only).
>>     
>
> filesystem metadata based on just size + inode + mtime is never a
> guaranteed change identifier. Nothing stops an in-place edit where the
> timestamp is kept.
>   

Yes but in the first paragraph you are excluding these sub second file 
system access anyway :) . Excluding sub second direct file system access 
and with the addition of a modification counter it would be enough? (or 
by making PUT without Content-Range change the inode).

The isolation levels should perhaps be discussed independently as this 
is leading to some of the confusion. Here is my take on it:

dav+fs (assumptions of current code)
 * needs to generate a weak ETag for subsecond mtime unless it could 
detect sub second modifications or use a mandatory lock for 1 second.
 * it can't detect sub second modifications and doesn't use a mandatory 
lock for 1 second.
 * storing ETag will not improve your ability to generate a strong ETag 
(unless you could detect the direct filesystem modifications or use a 
mandatory lock).
 * if you could detect the direct filesystem modifications or use a 
mandatory lock then mtime+inode+length (+ modification counter) would be 
enough (although this would exclude mmap modifications on unix)
 * sub-second direct modifications can't be detected easily (requires 
non portable interfaces like inotify) and mmap changes can probably 
never be detected.

dav-only
 * could generate strong ETags always if sub-second mod_dav 
modifications were tracked somehow.
 * mtime+inode+length (+ modification counter) would be enough (what 
more is needed? no changes are happening outside mod_dav)
 * probably needs to store modification/generation counter, although...
 * if PUT without Content-Range was made to change the inode then most 
of the common cases could probably be covered without storing anything 
(although this would not cover the case where the ETag would need to 
change on sub second PROPPATCH?? and PUT with Content-Range - how common 
is this?).

Perhaps there is a third isolation level?:

dav+loose-fs
 * only differs from dav-only in that it makes a best effort at handling 
FS changes.
 * could incorrectly return a strong ETag in cases where a direct file 
system modification was made in the same second as a mod_dav modification
 * mtime+inode+length (+ modification counter) would be enough?
 * Is this any different from dav-only? Is this just an alias for dav-only?


Mime
View raw message