Re: Summary of ETag related issues in RFC2518bis

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