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

CommentFileSizeAuthor
#3 304_spec_0.patch828 bytesjhenry
304_spec.patch741 bytesjhenry
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

jhenry: 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.

jhenry’s picture

Code 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.

jhenry’s picture

FileSize
828 bytes

File attachment.

Dries’s picture

Status: Needs review » Fixed

Committed to CVS HEAD. Thanks!

Anonymous’s picture

Status: Fixed » Closed (fixed)