RE: Stronger requirements for ETags

> ...
>
> So, what now?  Does the current language (03) make mod_dav or IIS 
> (or other implementations) uncompliant with 03?  Is that a 

I think so, because both use a "promotion strategy", in which upon PUT only a weak ETag is returned, which, after some delay, is "promoted" into a strong ETag.

> problem?  Would it be a bad idea to upgrade mod_dav or IIS to 
> become compliant with RFC2518bis if it goes to RFC with these 

Of course that would be good, but these servers use this approach for a very good reason (being that they *can't' produce the strong variant at resource creation time).

> requirements?  I'd point out that there are other changes that 
> already make servers slightly uncompliant with RFC2518bis -- e.g. 
> the removal of specially-behaving lock-null resources makes 
> existing servers supporting lock-null resources "uncompliant".  

True.

> But being uncompliant with a spec that the server doesn't declare 
> compliance to shouldn't be a problem!  A server will continue to 
> be compliant with 2518 because that can never be replaced. Server 
> implementors may upgrade their code/product to become compliant 
> with RF2518BIS (whatever rfc number that turns out to be) and 
> then declare compliance with that new, more stable standard.

True as well.

My primary concern is that if we put in a change that isn't and furthermore *won't* be implemented by the two must widely used implementations, we have a severe problem with the spec. So it would be really good to understand the issue (maybe Greg Stein can say something about it) and find out whether at least Apache/mod_dav is going to be updated.

I personally see no use in the "promotion" strategy. If you can't produce a useful ETag upon PUT, don't.

> IF the language must be weakened, is there any point to this at 
> all?  I'm afraid we've got to make a hard choice.  Either we do 
> something real to encourage ETag support, even though it makes 
> existing servers "uncompliant".  Or we do nothing, and we leave 
> the problem unmitigated.

But then there's the risk that popular servers like mod_dav never will be updated to RFC2518bis conformance, just because it ask for things that can't be implemented. Or worse yet, the servers may claim compliance although they don't comply.

So I agree to any kind of text that explains *why* strong ETags are important, but I object to make them mandatory unless we can at least mod_dav support them properly.

> As a server implementor, my personal opinion is that it's a good 
> idea to make, and follow, stricter requirements for ETag support. 
>  It's so helpful to clients and users (in terms of robust and 
> reliable distributed authoring) that it's worth the cost.   

How do you calculate the cost in the case of mod_dav/fs, where clearly robust strong ETags can't be calculated without having additional metadata? Keep in mind that mod_dav is just an extension to the base HTTP server, such mod_dav's ETag handling must be identical to Apache/Httpd's.

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 22 June 2003 10:07:29 UTC