Re: Summary of ETag related issues in RFC2518bis

Most of these things came up in interoperability tests, and it seems  
from those experiences that most existing WebDAV clients expect servers  
to behave as remote file systems.  It's the most common use case out  
there and the reason why WebDAV is now deployed on all Windows and Mac  
platforms.

Other uses of WebDAV are emerging and sometimes these do not need all  
these requirements or some such requirements might even be harmful to  
certain cases as you point out.

Thus, I'd be happy with a new compliance class that a server could use  
to advertise this set of capabilities.  Some existing servers would be  
able to advertise that almost immediately.  That new compliance class  
probably shouldn't be called 'bis' - perhaps we can come up with  
another word or declare this as level 3 because it's still rather core  
stuff.

Lisa

On Dec 19, 2005, at 11:07 AM, Julian Reschke wrote:

>
> 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:23:28 UTC