Re: ETags?

On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote:
> When I first considered ETags and bindings, I assumed that all 
> bindings to the same resource MUST show the same ETag.

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.

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.

....Roy

Received on Wednesday, 19 January 2005 22:08:55 UTC