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, JulianReceived on Tuesday, 2 March 2010 12:08:01 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC