Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 09, 2005 2:39 AM > New Revision: 152973 [...] +/* RFC 2616 10.3.5 states that entity headers are not supposed + * to be in the 304 response. Therefore, we need to load in the + * cached headers before we update the cached headers. That's not how I read that section. 14.26 has some specific text stating cache-related header fields should be included. Sander
Re: Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
--On Wednesday, February 9, 2005 10:47 AM +0100 Sander Striker <[EMAIL PROTECTED]> wrote: [...] +/* RFC 2616 10.3.5 states that entity headers are not supposed + * to be in the 304 response. Therefore, we need to load in the + * cached headers before we update the cached headers. That's not how I read that section. 14.26 has some specific text stating cache-related header fields should be included. Section 10.3.5 says: If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. The headers specifically listed are: Date, ETag and/or Content-Location, Expires, Cache-Control, and/or Vary. Hence, the response headers from the origin server on a 304 response aren't guaranteed to be complete. So, what this commit does now is load in the stored cached response headers and interleaving them with the headers we just received as part of the 304 response - retaining the just-received headers if there is overlap. Then, we're updating our cache entry with this new merged set of headers. The issue here is that you can't just take the response headers from a 304 header and use them and them alone to update the cache: you need to 'merge' in what you already have to be complete. As an aside, see line 934 in modules/http/http_filters.c for what httpd sends on a 304: all other header fields are stripped. Or, do you see a better way? Or, is there a way to make the comment clearer? -- justin
RE: Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 09, 2005 6:20 PM [...] > Hence, the response headers from the origin server on a 304 response aren't > guaranteed to be complete. So, what this commit does now is load in the > stored cached response headers and interleaving them with the headers we > just received as part of the 304 response - retaining the just-received > headers if there is overlap. Then, we're updating our cache entry with this > new merged set of headers. Yeah, I misread the comment. > The issue here is that you can't just take the response headers from a 304 > header and use them and them alone to update the cache: you need to 'merge' > in what you already have to be complete. Sure. > As an aside, see line 934 in modules/http/http_filters.c for what httpd sends > on a 304: all other header fields are stripped. Ah yes, makes sense. Nice to have a guard on the way out. > Or, do you see a better way? Or, is there a way to make the comment clearer? I think I've clarified the comment slightly in rev 153104. But honestly, it was just me. Sander