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
