Re: Etag-on-write, 4rd attempt (== IETF draft 03), was: I-D ACTION:draft-reschke-http-etag-on-write-03.txt

Wilfredo Sánchez Vega schrieb:
> 
> Julian-
> 
>   I apologize for the absurdly slow response, but here goes.  Overall 
> feedback: I think this is excellent.

Good to hear.

> Section 1.2:
> 
>   I'm not sure the "Furthermore" note is interesting.  Of course it is 
> possible that one a resource is put onto a server that it's body may 
> change again later.  Whether that happens via a PUT request, or via 
> PROPPATCH, or even outside of HTTP altogether isn't really all that 
> relevant.  What matters is that changed content requires a changed ETag, 
> and that's already quite clear in HTTP.

I thought it was worthwhile mentioning this because I've heard from 
clients struggling with this problem (at interop events).

>   OK, this becomes clearer when we get to section 5...
> 
> Section 1.2:
> 
>   The t(e2(e1(c))) = t(e2(t(e1(c)))) explanation is very useful.

Thanks.

>   As a general note, I still don't quite understand the widespread 
> aversion to weak ETags, and I think that the this editing property show 
> why weak ETags *do* work in an authoring environment.  That the server 
> might give you a different-but-equivalent representation isn't a problem 
> if any "equivalent" version of the document can be edited by a client 
> and sent back to the server and produce an "equivalent" result in the end.

I do agree in general. The problem is that to include weak Etag 
discussion into this draft would mean to make it more complicated, and 
there are so many people not getting weak etags that it would likely 
complicate and delay this specific issue.

>   I'm rather annoyed that CalDAV was short-sighted here and insisted 
> that all calendar resources must have strong ETags when a weak ETag 
> could be entirely appropriate, but then I think the entire section 5.3.4 
> in CalDAV was hasty and poorly thought out.

Right. In particular it defeats etag support in editing calendar entries 
when the server has rewrite the contents (for instance because the back 
end is a calendaring system, not a "generic" store).

So -- out of curiosity -- what is Apple's server doing with respect to 
this requirement?

> Section 4:
> 
>   I think it's useful here to say something about weak ETags.  In 
> particular, I would expect an entity-transform-keyword of "identity" 
> followed by a weak entity-tag to indicate that a semantically equivalent 
> entity was stored, not an octet-by-octet copy.  Thus, a user agent MUST 
> NOT assume an octet-by-octet entity was stored if a weak ETag was assigned.

Well, the way it's written a weak ETag can never appear with "identity". 
I just added an attempt to clarify that, see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html#rfc.section.4>).

Note that the extensibility rules would allow future definitions, such 
as "semantic-identity" to be used with weak ETags.

>   I suppose another entity-transform-keyword could indicate semantic 
> equivalence, but that's already covered by the nature of the ETag.

I think strong vs weak is somehow orthogonal to rewrite vs no-rewrite, 
so the Entity-Transform header may be useful for weak ETags as well.

> Section 4.1:
> 
>   What's an example of a situation in which a server would send you a 
> stale Entity-Tag header?

A server wouldn't, but a client might get one due to a proxy 
understanding the header as entity header.

> Section A.1:
> 
>   This example works well to illustrate what you are trying to explain, 
> but, for what it's worth, doesn't work well for a Subversion client per 
> se.  The reason being that the whole point of the $Revision$ keyword is 
> that it shows you want revision of a document you have checked out in 
> your working copy.  That is, which is doesn't matter in terms of the 
> integrity of the authoring process (what you are explaining), it does 
> matter for it's intended usage, which is as an informational bit of text 
> maintained by the subversion software in your document.
> 
>   That said, in this particular case, the client should understand this 
> aspect of how the protocol works, and it should be able to modify the 
> $Revision$ text in the document itself without having to follow an edit 
> with a GET request, assuming that it knows that the ETag == the revision 
> number.  That may not work for other keywords, though.

Hm. So do you propose to use a different keyword, which the client would 
be able to update itself?

> Section A.2:
> 
>   This is a particularly notable example if the client did a LOCK 
> operation, followed by the PUT and PROPPATCH in the example, in which 
> case a client might have more reason to assume that the content hasn't 
> been modified since the PUT operation, since no other client could have 
> made an edit in the mean time.

OK, so would it make sense to add a note stating that in a case like 
this, even the presence of a WebDAV lock wouldn't have helped the client?

> Section A.2:
> 
>   Note that in Request (3), the title property sent contains spaces and 
> newlines which were removed in the new entity body shown.  So even in 
> the PROPPATCH example, there is some server-side transformation of sent 
> data going on.  Obviously the Entity-Transform header can't help us here 
> due to the Multi-Status response, but one might imagine an equivalent 
> sort of thing in a new child of the the propstat element.

Good catch - I just fixed the example so that the whitespace indeed 
matches 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html#rfc.section.A.2>).

> More on Entity-Transform:
> 
>   An Entity-Transform example with a transformed entity might be 
> useful.  (I like lots of examples.)  Perhaps an example of PUTing JPEG 
> image data where the server stores it as PNG?  It's easy to turn this 
> into a rat-hole, I suppose; what if the transform is lossy (PNG->JPEG), 
> etc.?  Is that worth exploring here, or too zany?

I guess I should add the Entity-Transform header to a variant of the 
example in Appendix A.1...

>   Perhaps limiting the example to something that's easily transformable 
> both ways is best.  iCalendar <-> hCalendar, for example.  Of interest 
> here is the change of Content-Type.
> 
>   I reckon that you may have lets this out intentionally, to be 
> addressed later.  I'm just trying to think of cases where this draft 
> might make that sort of operation harder than necessary... not thinking 
> of any as yet.

A server always has the freedom not to send the header, so I don't think 
it ever gets harder...

> More on weak ETags:
> 
>   I think there is room for a weak ETag example here, new style.  I'll 
> assume for now that my comment about the "identity" 
> entity-transform-keyword makes sense:
> ...

Understood, but I think starting to talk about weak etags in this 
context will make it much harder to get this done. When I wrote this, I 
was hoping to prevent other authors to profile HTTP in incompatible 
ways; exactly what we now have with XCAP and CALDAV. So timing is really 
important here; I don't want it to take years :-) .

Best regards, Julian

Received on Sunday, 5 November 2006 18:42:04 UTC