The HTTP/1.1 Spec states that an ETag must be present in the header of a 304 response if the ETag would have been sent on a 200 response. Since the ETag is sent on all 200 responses from the Drupal cache, the 304 must also send the same ETag.
Also, If-Modified-Since (IMS) requests are not part of the HTTP/1.0 spec, so the correct response is: HTTP/1.1 304 Not Modified
As an aside, the ETag should be something other than md5(time()), but I've got plans for that in another patch.
Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 304_spec_0.patch | 828 bytes | jhenry |
| 304_spec.patch | 741 bytes | jhenry |
Comments
Comment #1
dries commentedjhenry: nice catch. How did you discover this, or how did this affect your website's behavior?
One small remark: care to add a code comment? It's one of those things no one will be able to grok, unless there is a small code comment. Otherwise, this patch looks good.
Comment #2
jhenry commentedCode comment added.
I discovered this when trying to discern why my content distribution network was ignoring the expires information that I was passing to it and caching documents for way too long. I am not adding my expires change to the patch because drupal tries very hard not to be cacheable by emitting uncacheable headers. Expires is not required in the HTTP/1.1 spec if the value of the field is the same as the 200 response, however, and omitting it is fine.
Comment #3
jhenry commentedFile attachment.
Comment #4
dries commentedCommitted to CVS HEAD. Thanks!
Comment #5
(not verified) commented