Re: ETags, next call, was: Notes on call from today ...

Lisa Dusseault wrote:
> 
> 
> On Nov 27, 2005, at 7:59 AM, Julian Reschke wrote:
>>
>> In particular I'm surprised to hear that implementors of CalDAV 
>> clients expect the servers to provide strong ETags for calendar 
>> entries. A calendar server that has a ICS store has basically the 
>> following options:
>>
>> - store the binary representation sent with PUT for every entry 
>> (expensive), or
>>
>> - do not return an ETag at all after PUT, because the ETag returnen 
>> upon GET will depend on what the server's default binary 
>> representation of the calendar object will be (and that's unlikely the 
>> same as sent by arbitrary clients)
> 
> Another option is for the server to store the calendar data in some 
> internal format (e.g. nodes) and have a consistent way of constructing 
> the entity from that.  As long as the server has an algorithm that 
> generates the same bytes each time from the underlying data, it can use 
> the same ETag.

That's exactly what I just said. But the problem here is that if the 
server does that, it can't return an ETag upon PUT. As far as I can 
tell, returning a strong ETag in the response to PUT signals that the 
server has stored the message body binary, and that the ETag applies to 
that content (not the internally rewritten content the client may see on 
the next GET request).

> It also doesn't matter what format the client sends the event in: the 
> ETag refers to the octets the server sends, not to the octets the client 
> sends.

How do you know that? RFC2616 in fact doesn't define at all what an ETag 
in a response to PUT means 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.19>):

"The ETag response-header field provides the current value of the entity 
tag for the requested variant."

Note that PUT doesn't request any representation/variant, thus the text 
doesn't even apply. I guess that's another reason why RFC2518bis MUST 
NOT make any statements about ETags in PUT responses. This really needs 
to be coordinated with the base spec.

> It also doesn't matter if the client can request variants: for example, 
> a server can keep one ETag around for the iCalendar version of the 
> event, and a separate ETag for the xCalendar version of the event if it 
> can generate two formats (both consistently).  Both ETags would have to 
> change if the event data actually changed, of course.

That may be true, although "common wisdom" (i.e. afair Roy's) is that 
resources that are content-negotiated better not be authorable.

>> On the other hand, a server that implements RFC2616/RFC2518 would just 
>> use weak ETags, allowing to reformat the content as long the semantics 
>> stay the same.
> 
> How do weak ETags solve this?  What can a client really rely on if the 
> weak ETag is the same, or different?  Do you believe a client could rely 
> on weak ETags to do synchronization?  Wouldn't we need restrictions on 

Yes, I would think so.

> what changes could be allowed before the weak ETag had to change in 
> order to use weak ETags?

<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.11>:

"A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two 
entities of a resource only if the entities are equivalent and could be 
substituted for each other with no significant change in semantics. A 
weak entity tag can only be used for weak comparison."

> I haven't seen weak ETags be useful to clients except in two cases:
>  - possibly for a client doing GET only (not an authoring client, and so 
> it doesn't care about obtaining exact copy to author from)
>  - a client that has inside information about what a server does -- e.g. 
> a client with a coding dependency on the behavior of Apache which is to 
> switch from a weak ETag to a strong one.

Best regards, Julian

Received on Tuesday, 29 November 2005 09:25:53 UTC