On 14.08.2008, at 23:20, Wilfredo Sánchez Vega wrote:

Our ETags are usually MD5 sums, not timestamp-looking things. Is this for non-calendar resources?

No. Anyways, I couldn't reproduce the issue easily, hm. Will watch it and come back on it if necessary.

I'm not aware of any cases where we stick on "-gzip", for example.

You never do. Its a special Apache/libneon hack :-) Which per RFC should not confuse you. When Apache send a resource with content-encoding: gzip, it adds "- gzip" to the ETag (for no good reason. While different etags for different content representation are allowed, its not required either. Unfortunately libneon does not seem to support TE out of the box). Anyways, we send an conditional GET to catch both cases: If-None-Match: "abc", "abc"-gzip and CalServer should just check whether one of the two does not match (it works fine with Apache). I had the impression that CalServer gets confused by multiple etags in the if-none-match header, but as I said I can't reproduce it easily. Thanks, Helge

On Aug 4, 2008, at 3:42 AM, Helge Heß wrote:

...

Hi,

I'm using GET with an if-none-match header to check whether content changed on the server, it looks like:

If-None-Match: "20080725T101321Z-0", "20080725T101321Z-0"-gzip

CalServer always returns me the full content, that is a 200 OK status. (I'm expecting a 304).

Is it possible that CalServer/TwistedCalDAV does not check all the given tags for a match? Or does it use a different etag with content-encoding content, like Apache?