Summary of ETag related issues in RFC2518bis

Hi,

below is a summary of issues related to changes to ETag handling 
requirements. Feedback appreciated.

Best regards, Julian

-- cut --



RFC25128bis has some new server requirements, and some more are 
currently discussed. All of them fall into the category of transforming 
WebDAV into a kind of distributed file system. I absolutely agree that 
this is one important scenario, and that many clients already assume 
that they can rely on these things. So it's a real-world use case, I 
just happen to think there are lots of others, and making WebDAV 
incompatible with these would be a step into the wrong direction.

The individual changes that have been discussed (or dropped into the 
draft are):

R1) Require servers to support strong entity tags,

R2) Require servers to return entity tags for PUT requests,

R3) Require ETags not to change when only properties or lock state change,

R4) Require servers to store arbitrary binary content,

R5) Require servers to store dead properties,

R6) Require servers to use persist Content-Type upon PUT.


(If there are more, please let me know).


Let's discuss them one by one:


R1) Require servers to support strong entity tags

Weak ETags are adequate for cacheing (optimizing GET operations), but 
not authoring (they can't be used with PUT):

"Clients MAY issue simple (non-subrange) GET requests with either weak 
validators or strong validators. Clients MUST NOT use weak validators in 
other forms of request."

So I do agree that putting in a SHOULD support strong ETags makes sense, 
as long as we don't make existing compliant servers non-compliant. That 
is, we shouldn't require them to return anything upon PUT, and we also 
should let them upgrade weak ETags to strong ETags if that makes sense 
to them.


R2) Require servers to return entity tags for PUT requests

The idea is that a client that did a PUT immediately will know the etag 
for the entity, and can use that in future requests for syncing. The 
trouble here is that RFC2616 doesn't really define what it means to 
return an ETag upon PUT, see discussion thread at 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/thread.html#13>. 
So, at a minimum the WebDAV WG will have to clarify what it means, and 
make *absolutely* sure that this clarification is added to the RFC2616 
errata.

Assuming we had consensus on what an ETag upon PUT means (such as "an 
ETag for the entity you'd get upon a subsequent GET"), I'm still not 
sure how this helps with syncing. Servers are allowed to rewrite content 
upon PUT, so a client would still need to do another GET in order to 
retrieve the new entity body (that is, except if we also require R4).


R3) Require ETags not to change when only properties or lock state change

This is just broken spec writing, sorry. The guarantee that HTTP gives 
us that the ETag will change if the content changes, that's it. Of 
course it's sub-optimal if the etag changes when the content didn't, but 
a server may have very good reasons to do so. So yes, if the Etag 
changes the client may have to resync, just to find out that nothing 
changed, after all.

I do understand that clients ran into problems because of repeating the 
sequence

   PUT, then PROPPATCH

assuming that PROPPATCH wouldn't modify the ETag. As far as I can tell, 
a safe way to do this seems to be

   PUT, the PROPPATCH and HEAD to get the current ETag

(potentially with a WebDAV lock).



R4) Require servers to store arbitrary binary content

There are servers that don't, examples may be Atom servers, Calendaring 
servers, and any kind of server that uses HTTP/Webdav to expose specific 
types of resources with no generic store available.

Even if this would not be the case, I have to point out that the spec 
currently mentions scenarios where servers may rewrite content without 
notice (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.19.8>).


R5) Require servers to store dead properties

RFC2518 says this is a SHOULD. Meaning, servers may not allow it, and I 
think this clearly reflects reality. Checking for PROPPATCH in the 
"Allow" header will not always work, because there may be servers which 
support PROPPATCH for just a limited set of properties (such as a server 
that only supports setting properties in a single namespace - no 
kidding, that one exists).


R6) Require servers to use persist Content-Type upon PUT

I think that's the best thing to do, but there are servers / resource 
types which will ignore that, and (try to) detect the type on their own. 
  IMHO that's not optimal, but given the fact it's the preference stated 
in an upcoming TAG finding 
(<http://www.w3.org/2001/tag/doc/mime-respect-20051205>), I don't think 
we can make this more than a SHOULD.



So what next?

I strongly object to any attempt to transform WebDAV into something like 
NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has been 
designed for a wide variety of resource types, not only serving files. 
The good thing is that I'm almost sure that the IESG wouldn't let us do 
that anyway.

On the other hand, I do understand that certain types of clients will 
not work well with servers that can't provide some of these features. 
Those who like to add new requirements thus should gather feedback from 
the client implementors, collecting information so that we really 
understand what these requirements are (right now it seems we're still 
guessing). My feeling is that this will include

a) support for strong etags
b) some way of discovering whether a given resource will allow storing 
arbitrary contents, or just some specific content type
c) some way of discovering whether a given resource will allow storing 
arbitrary dead properties

If this is what these clients need, let's extend the spec so that they 
can find out. But if we can't finish this within the next few weeks, 
then I certainly think that we should leave things as they were in 
RFC2518, and have a separate spec take care of this.

Received on Monday, 19 December 2005 19:09:18 UTC