RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, February 26, 2003 8:36 PM
> To: 'Jason Crawford'; 'Clemm, Geoff'
> Cc: 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>
>
> > Just so that you know you're not alone... what Julian suggests sounds
> > reasonable.
>
> OK, this is really starting to sound like consensus, but I want to make
> sure we explore the options.  I don't want to accept a consensus based
> on arguments that I don't think are valid, even if the consensus might
> be right I'd like to know why by seeing valid arguments.
>
> I've attempted to rebut the two arguments I believe to be invalid.
> Please explain why I'm wrong if you think the arguments are in fact
> valid (perhaps I haven't understood the arguments).  Or, please explain
> what other arguments remain for making Etags optional.
>
> 1.  The argument that "Etags are too difficult to support".  Is the
> problem with strong etags that they're hard to implement for all
> resources? Or only for PUTtable resources? The requirement could be that
> servers supporting "bis" MUST support strong Etags in response to
> successful PUT requests.   Given this, I think it's easy.
>
> RFC2616 only says:
>    A "strong entity tag" MAY be shared by two entities of a resource
>    only if they are equivalent by octet equality...
>
>    An entity tag MUST be unique across all versions of all entities
>    associated with a particular resource. A given entity tag value MAY
>    be used for entities obtained by requests on different URIs. The use
>    of the same entity tag value in conjunction with entities obtained by
>    requests on different URIs does not imply the equivalence of those
>    entities.
>
> That means that Etags could be almost as simple as a sequence number
> plus possibly some file/url string.  A digest of the contents would also
> work. Supporting strong etags is actually easier than supporting weak
> etags.  It may be slightly time-consuming to generate etags depending on
> what algorithm you choose, but the time is insignificant compared to the
> time it takes to receive a PUT request, check access controls and store
> the body.

Can we agree that the fact that both IIS and moddav only return weak etags
upon PUT indicates a problem?

All you say is correct, yet the two most widely used HTTP/WebDAV servers
just don't do that. Why is that? As far as I understand it's because they
try to be very efficient HTTP servers while also supporting WebDAV. Thus,
their etag handling is completely independant of their WebDAV code (and
property persistence). So, there's no way just to store it somewhere -- it
needs to be computed out of the file's attributes (for those backends which
are file based). Computing a digest upon every GET and HEAD is clearly not
an option due to performance reasons.

Maybe Greg Stein can say more about why moddav works the way it does, but
that's my understanding.

> Next, no WebDAV server should have any problem storing the ETag. Any
> server capable of storing dead properties is capable of storing an etag
> generated on PUT.  A server that cannot store ETags is already likely to
> be massively non-compliant.

See above.

> I might consider a cost-benefit argument to be a valid argument --
> although I believe the benefits are high and thus the cost would have to
> be even higher to outweight.  However, I don't consider "too difficult
> to support regardless of the benefits" to be a valid argument.

I think the problem here is that for both moddav and IIS, it's simply
infeasable to provide strong etags upon PUT and be an efficient HTTP server
at the same time. If you can think of a way to fix this, I'd be interested
to hear how.

The other problem that I see is that if we require strong etags, server
implementors may

1) try harder and possibly come up with strong etags,

2) just ignore the requirement or

3) claim that their etags are strong when in fact they aren't.

1) would be nice, 2) means that clients haven't won anything at all, 3)
would really be a disaster.

If our goal is to get implementors to provide strong etags, we should try to
*convince*, instead of trying to *force*.

> 2. If 2518bis requires support for Etags, this doesn't retroactively
> make servers like IIS5.0 non-compliant with 2518.  That's a historical
> standard and we can't change that even if we wanted to.

For obvious reasons I'll not argue about IIS. But if RFC2518bis mandates
behaviour that Apache/moddav simply can't provide, I think there's something
fundamentally wrong with the requirement.

> On the other hand, there will be several requirements 2518bis which will
> make servers compliant with 2518 have to do some work to be compliant
> with 2518bis:
>  - Making LOCK on an unmapped resource create a regular empty locked
> resource (not a lock-null resource)
>  - Supporting commas in if header syntax

Both are likely simple fixes to the moddav code.

>  - Evaluating all clauses in an if header even if they are tagged with a
> URL to which the request does not "apply"

...can you point me to the relevant discussion about this change...?

>  - etc...
>
> Given that we are already making more requirements on servers in 2518bis
> than we did in 2518,  I do not see the "making servers non-compliant"
> argument as a valid argument.

As I said, it depends on the nature of the change.

Julian

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

Received on Wednesday, 26 February 2003 15:10:54 UTC