https://issues.apache.org/bugzilla/show_bug.cgi?id=54706
Yann Ylavic <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #30107|0 |1 is obsolete| | Attachment #30260|0 |1 is obsolete| | --- Comment #9 from Yann Ylavic <[email protected]> --- Created attachment 30330 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30330&action=edit Compute the cacheable headers once An update to the patch since the code has changed in trunk. Any news here? Maybe I should comment a bit more about the patch, so here... This patch (re)associates the cache_request_rec to the request_config, not that I'm nostalgic for the 2.x code (I guess it was avoided in the new code for good reasons), but to compute the cacheable headers once per request (ie. strip CacheIgnoreHeaders/cache-control'ed/hop-by-hop headers once), without breaking the API. The new cache_prepare_headers() function does what was done by ap_cache_cacheable_headers_in/out() before and, optionally, also calls cache_accept_headers() to merge the stale response headers. I'm not sure whether this function should be in cache_storage or cache_util though, and chose the former (near cache_accept_headers()) but that required a move of the static cache_control_remove() from cache_util to there, and #include "cache_storage.h" in "cache_util.c". The other option is to move cache_accept_headers() to cache_util since "cache_util.h" is already included by "cache_storage.c", but my feeling is that cacheable headers relate more to storage... By keeping the cacheable headers separatly from the request's headers_in/out (actually in the cache_request_rec), the patch fixes the problem raised in comment #3. It also fixes the CACHE_SEPARATOR macro which contains multiple spaces and no tabulation (unfortunate ^I replacement?). Finally, in the case where a revalidated response leads to a 304 (ap_meet_conditions), the patch unsets the entity headers which have been merged from the stale entry before passing the response to the filter stack. Maybe all this changes should be splitted in different patches, or this patch is broken, let me know... -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
