- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 02 Mar 2010 13:07:24 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 02.03.2010 12:53, Maciej Stachowiak wrote: > Using If-None-Match this way seems like a bad fit in a couple of ways: > > - Event IDs are not ETags at the HTTP level. It seems like a layering > violation to treat event IDs, or indeed anything in the response body > rather than in the ETag header, as entity tags. Event IDs *could* be used as ETags, in which case there wouldn't be a layering violation. > - If-None-Match does a conditional GET. But a 304 response to an > EventSource request would not make sense under any circumstances. The > server should wait until it has more events to send, not tell the client > to consult a cached copy. The client likely won't even have a cached copy. The server is not strictly required to return a 304 (it's not a MUST). As this is a protocol extension in any case, I think that use would be ok. But I agree, it's a bit of a stretch compared to the Vary:if-none-match pattern used for feed retrieval, as in that case, the server really returns 304 when there was no change. Best regards, Julian
Received on Tuesday, 2 March 2010 12:08:01 UTC