Re: i22: ETags on PUT responses

Werner Baumann wrote:
> 
> Julian Reschke wrote:
>> My understanding is that your proposal changes the semantics of 
>> RFC2616,  breaks existing servers, and rules out lots of applications 
>> what work fine today.
>>
> Your examples:
> XCAP, CalDAV and AtomPub. They are protocols, defined in an RFC. These 
> protocols (hopefully) clear the matter of rewriting by the server. When 

Some do. But how, in general, does this help a client that doesn't have 
out-of-band knowledge what the resource is?

A CalDAV resource is a WebDAV resource, however it's likely to rewrite 
the content upon PUT. But then, maybe the implementors did the 
additional work to preserve the binary you sent in PUT. You just don't 
know, and RFC2616 doesn't give you any information *on the wire* to find 
out. So if you *need* to know, you'll have to do the additional GET.

> a client and a server use one of these protocols, this is clearly caught 
> by "unless it knows that the client is aware of this changes and can 
> handle them". There is no conflict and nothing is ruled out.

So what do you do in a library that doesn't know the specifics of these 
protocols? Or in a server that attempts to support multiple protocols in 
the same URL space?

> I don't know about JCR, JCS and ICS. Please give me the full names.

JCR - Java Content Repository - an hierarchical store that's likely to 
expose content rewriting when accessed over HTTP.

JCS - no idea. Did I say that?

ICS is the file format you'll usually manipulate over CalDAV.

> Example A.1 and A.2 of draft-reschke-http-etag-on-write-08 is about 
> version control. There are protocols for this. See above.

I'm not sure how the fact that there are protocols for that invalidates 
the point. As a matter of fact, the only sort-of-standard for that I'm 
aware of would be RFC3253, and a versioning server supporting keyword 
expansion and RFC3253 would expose exactly that behavior.

> Example A.3, A.4 is an example that will not work without additional 
> knowledge. It is some kind of server-side-include and not very 
> realistic. Authors of a website will want to use WebDAV to edit the 
> *sources* and not the output from server-side processing of this sources 
> (which is intended for normal, none-WebDAV-access with GET).

Well, it has been implemented, so I'm not sure how you can say it's not 
"realistic". And it has nothing to do whatsoever with 
server-side-includes, but with automatic extraction of meta data from 
content, and automatic insertion of meta data into content.

> Other examples? Clients that just know about RFC 4918 and that use 
> simple WebDAV-servers like Apache/mod_dav/mod_dav_fs or IIS for 
> distributed authoring. They will never be able to make use of etags in 
> PUT-responses, when it is defined according to your proposal.

You are still focused on HTTP-as-a-filesystem-replacement. That's really 
only one use case.

And, btw, the proposal I'm making in my internet draft tries to 
*address* the issue. It would give clients the information that's 
currently not on the wire.

BR, Julian

Received on Sunday, 6 January 2008 21:02:57 UTC