Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Roy T. Fielding schrieb:
> 
> On Sep 12, 2006, at 7:00 PM, Lisa Dusseault wrote:
>> Yes, this is a good analysis.  I know there are significant client 
>> deployments based on assuming no server-rewriting.  I am not aware of 
>> server deployments that do rewriting and return strong ETags.  I'm 
>> thus quite confident about where the interop advantage lies.
> 
> I agree.  As I said last time, the easier solution is to simply require 
> that
> ETag in a response to PUT means that the client can use that entity tag in
> future conditional requests (that includes IMS, If-Match, and Range-based
> conditional requests).  There is absolutely no reason for the server to 
> send
> an ETag on a PUT response if the server does not intend to support that
> functionality, and I am quite sure that none of the server vendors will
> care provided that the requirement is properly stated as an interface
> constraint and not an implementation constraint.

Let's be clear about that this breaks compatibility with RFC2616, and it 
also defeats real-world editing scenarios like the ones described by 
Yves Lafon and myself.

I prefer my own proposal, as it IMHO doesn't break any existing 
functionality, but only adds additional information for clients that care.

In any case, whatever the solution to this problem is should be 
described in a document that updates RFC2616, otherwise it doesn't 
really address the current problem I'm trying to solve (meaning that 
protocols using HTTP make conflicting requirements, as summarized in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.1.4>).

> OTOH, the mechanism for how the server "stores" the representation, whether
> or not it is stored byte-for-byte, and how a server might otherwise manage
> to accomplish the feat of handling a conditional request without preserving
> byte-level equality is none of our business and should never appear in an
> IETF specification regarding HTTP.

Here I fully agree. What I'd like to see as a result of the current 
discussion is a clarification on what clients can rely on, and - 
potentially and depending on that clarification - an extension that 
gives them the additional information they want.

Best regards, Julian

Received on Thursday, 14 September 2006 12:08:07 UTC