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

[Justin Erenkrantz]

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

[Sander Striker]

 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