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

[Julian Reschke]

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?

Best regards, Julian