W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Summary of ETag related issues in RFC2518bis

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Dec 2005 16:23:01 +0100
Message-ID: <43A97355.9020808@gmx.de>
To: Dan Brotsky <dbrotsky@adobe.com>
CC: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>, Jim Whitehead <ejw@soe.ucsc.edu>, WebDav WG <w3c-dist-auth@w3.org>

Dan Brotsky wrote:
>> Depends on what the target platform is. Apache is built on 
>> top of APR, (Apache Portable Runtime) as I recall, and that 
>> API may not have a guarantee of a higher timer resolution. 
>> What would be your proposal to the Apache guys how to handle that?
> I gave one below.

Sorry, I don't understand what your proposal exactly is.

>> Second, even in filesystems with millisecond resolutions, 
>> all the filesystem has to do is support exclusive 
>> write-locking and you can build a compliant server.  The 
>> server must simply keep the file locked long enough to avoid 
>> the milllisecond window and then set the time back to the 
>> write time in order to ensure that any interference is noticeable.
>> You mean "second" resolution, right?
> No, I meant millisecond.  Perhaps you are sugggesting that APR only supports 1-second resolution?  Why would that be?  I know of no filesystems with that kind of resolution.

I'm not sure why that would be, but the code in http_etag.c certainly 
uses a hardwired constant for this. Maybe this is fixable, in which case 
the problem would go away. Wilfredo?

>> Two problems here:
>> 1) Doing that may not be acceptable for mass uploads, where 
>> millions of documents need to be uploaded (don't tell me this 
>> isn't a use case...).
> Sure it's a use case.  But you don't explain why it's not acceptable.

On a fast link, it would slow down mass uploads unacceptably.

>> 2) Even then, it's not that simple. ETag and Last-Modified 
>> also have to be adjusted after COPY and notably MOVE (!).
> It's exactly that simple.  Because COPY and MOVE don't suffer the non-interference problem (on the target, that is), because the target doesn't exist for someone to have open.

I'm not sure I understand this. Let's try again; the considerations for 
generating valid ETags apply to all methods that change URL mappings 
(COPY, MOVE, PUT) as well. Are you disagreeing with that?

> ...
> No, I take that as an indication that everyone agrees that this bug is only there conceptually and that it never actually occurs in the field.  I know for a fact that the Adobe client implementations just ignored the weak marking on the etag and that's why they were interoperable with Apache.
>> So, Dan, can you make a concrete proposal how to change Apache/moddav?
> Yes: stop returning weak etags.  See above.

So instead return nothing at all, or a strong one?

Best regards, Julian
Received on Wednesday, 21 December 2005 15:26:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC