Re: I-D ACTION:draft-reschke-http-etag-on-write-00.txt

Roy T. Fielding wrote:
> On Aug 9, 2006, at 1:32 PM, Julian Reschke wrote:
> 
>> Personally, I think that we really need a very minor clarification, 
>> plus a simple new feature to help clients that want to avoid a 
>> re-fetch after sending the content. I therefore decided to write up my 
>> own draft. It summarizes the situation (as RFC2616 is concerned), 
>> proposes one clarification to RFC2616 (as mentioned in 
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006JanMar/0003.html>), 
>> and also proposes that minor new feature (a new response header).
> 
> No thanks.  A new response header will just be interpreted as an entity
> header...

That's correct, although I'm not sure how bad that is in practice.

First of all, if we restrict this for usage in PUT, intermediates 
shouldn't be a problem because 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6.p.2> says 
that responses to PUT aren't cacheable.

As far as the user agent itself is concerned, we can make sure that it 
knows about that header by making this an opt-in behavior. I thought we 
could avoid having a new request header as well, but if this is really 
required, we could do that.

> ... 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...

The basic question I'd like to see answered is whether clients - as per 
RFC2616 - can rely on an ETag being usable in conditional byte range 
requests. I think they can't (as the ETag is for what was stored, not 
what was sent), thus the attempt to make that piece of information 
available to the client.

> ...  How the server manages to accomplish that feat if it isn't
> storing things octet-for-octet is none of your business.

As demonstrated in the draft, in general conditional requests will work 
just fine. Problems only can occur when the client assumes it knows the 
exact content, for instance for a PUT with byte range.

OK, here's a thought: When a server wants to return an entity tag upon 
PUT (or related messages), and a transform did occur, it can return an 
ETag that is marked as "transformed content". That ETag will be usable 
for any operation that doesn't require octet-by-octet identity. For 
instance:

C1: PUT /x HTTP/1.1
     Host: example.com
     Content-Type: text/plain

     TestOne

S1: HTTP/1.1 201 Created
     ETag: "01234-temp"

(temporary etag assigned)

C2: PUT /x HTTP/1.1
     Host: example.com
     If-Match: "01234-temp"
     Content-Type: text/plain

     TestTwo

S2: HTTP/1.1 200 OK
     ETag: "01235-temp"

(validation ok, new temporary etag assigned)

C3: PUT /x HTTP/1.1
     Host: example.com
     If-Match: "01235-temp"
     Content-Type: text/plain
     Range: bytes=5,

     Three

S3: HTTP/1.1 412 Precondition Failed
     ETag: "01235"

(validation fails because octet-by-octet equality is required, so server 
says 412 and returns the final Etag).

Would that work? And even if it does, are user agents allowed to assume 
that every server works that way (I think no, they can't, but that's the 
issue I'd like to see resolved).

(And yes, I'm aware of weak etags, but 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.24> 
requires the strong comparison for If-Match, so they don't seem to be 
usable here).

> Note that this will solve your problem without requiring that the server
> become a filesystem, and is also consistent with XCAP (even though XCAP
> is a really bad use of HTTP).  In spite of the overspecification in CALDAV,
> the implementation will work fine as well for the above case.

Right now (and in the case of servers rewriting the content upon PUT), 
CALDAV disallows returning a strong ETag, while XCAP requires it. I 
really think that's a problem, so I think at least one of the two needs 
to be changed before it can be published on the standards track. I'm 
note sure we are in agreement here. Are we?

Best regards, Julian

Received on Friday, 11 August 2006 07:16:42 UTC