Re: ETags?

Roy T. Fielding wrote:
> Well, that assumption was in error.  Errors happen and no amount
> of specification can prevent them.  In particular, specifying the
> internal implementation of ETag just to prevent people from making
> erroneous assumptions about the interface is contrary to the design
> of HTTP. One person's need for etags will differ from the needs
> of others.
> 
> In Apache httpd, for example, the contents of default etags are
> configurable.  Some people will want the inode and last-mod,
> other people cannot include the inode due to use of clusters,
> while still others will use an MD5 hash of a pre-generated
> response message because their content is backed by a CMS.
> There is no way for the standard to guess all of the possible
> implementations of etags.
> 
> There are two sections to consider in the bindings draft:
> 
>   2.6  PROPFIND and Bindings
> 
>    Consistent with [RFC2518] the value of a dead property MUST be, and
>    the value of a live property SHOULD be, independent of the number of
>    bindings to its host resource or of the path submitted to PROPFIND.
> 
> which I consider to be in error because live properties are owned
> by the server -- any requirement that they be consistent across
> bindings is wrong.

I'm tempted to say "I told you so" (not to you, Roy :-). Although it 
would be certainly nice to be able to rely on that, we don't seem to 
able to mandate that.

> and
> 
>   2.7  Determining Whether Two Bindings Are to the Same Resource
> 
> which tells the implementer the right way to test for equivalence.
> 
>> So if I wrote a synchronizing client (which I am), and Brian wrote an 
>> authoring server (which he does), if we were guided only by the specs 
>> and our interpretations, we would probably have interoperability 
>> problems.
> 
> 
> No, you would have errors.  There is a difference between making a
> standard that enables interoperability and forcing implementations
> to use it correctly.
> 
>> Thus, I support adding text to bindings, either limiting the ways that 
>> servers can implement ETags and bindings, or explaining to clients the 
>> wide range of possible implementations they might have to deal with.
> 
> 
> Why do you insist on violating the basic design principles
> of an interface?  HTTP is supposed to support loose coupling
> of software systems, which means the standards cannot specify
> anything like what you describe above.  The specification is
> not the place to put tutorials on server design or lecture notes
> on potential implementations -- people can write books about that.

And they actually do that :-)

I'm also a bit concerned by attempts to turn WebDAV into something like 
NFS-over-HTTP. It can be used like that, but it's only *one* usage of 
it. Attempting to optimize WebDAV for that particular case (for 
instance, by adding new ETag requirements that in practice many servers 
will not be able to implement), IMHO is a bad idea, and I will continue 
to object to changes like that.

Best regards, Julian


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

Received on Wednesday, 19 January 2005 23:10:54 UTC