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

From: Jason Crawford <[email-masked]>
Date: Wed, 26 Feb 2003 13:54:23 -0500

Just so that you know you're not alone... what Julian suggests sounds
reasonable.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 26 Feb 2003 11:36:27 -0800

> Just so that you know you're not alone... what Julian suggests sounds

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. 

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.

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.

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. 

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
 - Evaluating all clauses in an if header even if they are tagged with a
URL to which the request does not "apply"
 - 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.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 26 Feb 2003 21:10:18 +0100

> From: [email-masked]
> [mailto:[email-masked]]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)
>
>
>
>

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.

> be massively non-compliant.

See above.

> 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*.

> 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.

>  - Supporting commas in if header syntax

Both are likely simple fixes to the moddav code.

> URL to which the request does not "apply"

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

> 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