[Ietf-caldav] Dead properties on CalDAV events / folders

Helge Hess helge.hess at opengroupware.org
Mon Dec 19 04:47:05 PST 2005

On 18. Dez 2005, at 17:19 Uhr, Julian Reschke wrote:
> Helge Hess wrote:
>> On 18. Dez 2005, at 17:01 Uhr, Julian Reschke wrote:
>>> This is a known specification issue: it's rather silent what it  
>>> means to return an ETag upon PUT. You seem to think it's for the  
>>> entity the client sent in the PUT request (this is what I thought  
>>> as well), while many people on the HTTP mailing list think it's  
>>> the ETag you would get upon a subsequent GET
>> You are right.
>> And yes, it reduces the issue. But still the implication is that  
>> an HTTP client MUST perform an immediate GET after the operation,  
>> eg with an if-match: put-result-etag. Otherwise there is no way to  
>> know the state the etag refers too and subsequent updates will be  
>> done based on incorrect assumptions?
> Hm.
> If it did that, and the server would return the ETag as described  
> above (representing the entity that the client would get upon GET),  
> then doing that refetch wouldn't help at all (because by definition  
> the result would be a 304).
> If the client really needs to know the exact octet stream he'd get,  
> there's no way to avoid GETting the resource. On the other hand,  
> why exactly would the client care unless it's going to use GET with  
> Range request headers?

Another very good point :-) I think many might not be aware that  
etags require an exact octet representation and I tend to forget that  
myself ...

The implication of this is that we cannot use etags in clients except  
with servers which actually store verbatim copies. Hm, not good?! Or  
maybe it is good and just puts more restrictions on the server (to  
store verbatim-copies), this would also render the whole x-  
discussion void.

So far I've usually implemented etags as markers for content which is  
"semantically" equivalent. Which of course is wrong if you implement  
HTTP strictly. In practice it works well _for me_ since clients  
usually do no range requests on calendar items and those would be the  
only case where verbatim representation matters?

Sidenote: what about returning the server side content in the PUT  
response if it changed, 201 + etag if it stayed the same and 200 +  
etag + content if it wasn't stored verbatim by the server. Might be  
an OK workaround?


More information about the Ietf-caldav mailing list