properties vs entity body, was: rfc2518-bis-04 issues (part 1)

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Elias Sinderson
> Sent: Thursday, July 31, 2003 1:39 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: rfc2518-bis-04 issues (part 1)
>
> ...
>
> No, implementation issues aside (that is, I don't care how a server stores
> properties as it is orthogonal to my position), ETags as defined
> in RFC 2616
> have nothing to do with WebDAV properties. The fact that resources have
> subsequently been defined as having properties doesn't change this fact.
> More to the point, the WebDAV specification should not change the
> definition
> or semantic properties of ETags.

I didn't propose that. However, if you look at RFC2616 you will note that it
really doesn't say that the ETag MUST NOT change unless the entity changes.
It only defines the other direction (the etag must change if the entity
changes).

> Let us, however, consider existing implementations where resource
> properties
> are stored as the same blob of bits as the resource entity. This situation
> does not imply that changing a property of a resource entails
> changing it's
> ETag. In this case, the server must know how to seperate the two when
> responding to a GET or PROPFIND request and is perfectly capable of
> modifying the ETag without taking property values into consideration. The
> fact that RFC 2518 doesn't treat this matter directly has certainly
> complicated the issue for implementors, as evidenced by the different
> approaches that server implementations have taken in generating ETags.

Actually, the case I raised is the one where properties are *extracted* from
the content, *stay* in the content and the content is *updated* when
PROPPATCH is applied.

For instance, (upon PUT) a server might use the HTML Meta tag to extract a
"foo:author" property and expose that as DAV property (making it available
for DAV:basicsearch...). Applying PROPPATCH to this property would affect
the content that you'll get upon a subsequent GET as well.

Now if you tell me that this behaviour is non-compliant we are in deep
disagreement about WebDAV. I understand that many see WebDAV simply as a
drop-in for filesystems or FTP. This is just one use-case, but there are
other scenarios that RFC2616 and RFC2518 explicitly allow.

> The two points you raise above are red herrings, if you ask me.
> In the first
> case you have stipulated that the client has done a PUT which affects some
> properties. This is, as you identify, a valid case for generating a new
> ETag, but this is simply because the client has done a PUT, not because of

No, it may affect any number of properties that are protected on that
particular server.

> any property value(s) changing (i.e. you have refuted my assertion that a
> PUT won't change properties, but not provided a compelling reason why
> changing properties alone should affect the ETag).
>
> In the second case you state that modifying some special properties may
> change the content of the resource. Again, I think this is a
> valid case for
> generating a new ETag, but not due to the property changing but
> because the
> resource contents have changed. In short, this is similar to
> doing a PUT and
> modifying the resource itself although it is accomplished via a PROPPATCH
> instead.
>
> In short, my argument is this: ETags should only change when the
> contents of
> a resource change (e.g. when the entity itself changes). Generating strong

OK, let's make that very clear: ETags SHOULD not change unless the content
changes. *However*, it's completely up to the server *which* methods affect
the content. For instance (in the case mentioned above), a PROPPATCH/set to
foo:author may affect the META/name=author tag in the HTML content that you
GET.

> ETags doesn't place an undue burden on server resources and neither does
> detecting when the actual contents of a resource have changed by
> any means.

I think that's a separate dicussion. We still don't have any feedback from
the two major WebDAV implementions (moddav and IIS) about whether they plan
to implement this according to RFC2518bis.

> There will be some frustrations in updating existing server code to be
> compliant if we take a firm stand on this issue but, in the long run, the
> benefits to clients far outweigh any drawbacks. The alternative is to have
> different server implementations of ETags and, as a consequence,
> balkanizing
> the interoperability of clients and servers.

Well the alternative obviously is not to change the requirement, and to keep
things as they are right now. I'm not convinced the current situation is so
bad we need to break compatibility with both RFC2518 and lots of existing
servers.

> Apologies for the long wind, I feel this particular issue is
> quite important
> and deserving of a thorough treatment on the road to consensus.

Yes.


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

Received on Thursday, 31 July 2003 03:13:40 UTC