httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: svn commit: r1591328 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c
Date Mon, 05 May 2014 13:27:25 GMT
Trying to get my 2.4.x reviews in.

Maybe I'm misunderstanding the change, but wasn't the previous
behavior more desirable?

If the entry were within its expiry, those same headers wouldn't have
been sent to the client (well, none but the first who filled in the
cache).  Why should it act differently just because it had to
revalidated with its own conditional?

On Wed, Apr 30, 2014 at 10:58 AM,  <ylavic@apache.org> wrote:
> Author: ylavic
> Date: Wed Apr 30 14:58:33 2014
> New Revision: 1591328
>
> URL: http://svn.apache.org/r1591328
> Log:
> mod_cache: Preserve non-cacheable headers forwarded from an origin 304
>            response. PR 55547.
>
> When mod_cache asks for a revalidation of a stale entry and the origin responds
> with a 304 (not that stale), the module strips the non-cacheable headers from
> the origin response and merges the stale headers to update the cache.
>
> The problem is that mod_cache won't forward the non-cacheable headers to the
> client, for example if the 304 response contains both Set-Cookie and
> 'Cache-Control: no-cache="Set-Cookie"' headers, or CacheIgnoreHeaders is used.
>
> Modified:
>     httpd/httpd/trunk/CHANGES
>     httpd/httpd/trunk/modules/cache/mod_cache.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1591328&r1=1591327&r2=1591328&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Apr 30 14:58:33 2014
> @@ -1,6 +1,9 @@
>                                                           -*- coding: utf-8 -*-
>  Changes with Apache 2.5.0
>
> +  *) mod_cache: Preserve non-cacheable headers forwarded from an origin 304
> +                response. PR 55547. [Yann Ylavic]
> +
>    *) mod_cache: Don't add cached/revalidated entity headers to a 304 response.
>                  PR 55547. [Yann Ylavic]
>
>
> Modified: httpd/httpd/trunk/modules/cache/mod_cache.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=1591328&r1=1591327&r2=1591328&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/cache/mod_cache.c (original)
> +++ httpd/httpd/trunk/modules/cache/mod_cache.c Wed Apr 30 14:58:33 2014
> @@ -1444,10 +1444,14 @@ static apr_status_t cache_save_filter(ap
>           * the cached headers.
>           *
>           * However, before doing that, we need to first merge in
> -         * err_headers_out and we also need to strip any hop-by-hop
> -         * headers that might have snuck in.
> +         * err_headers_out (note that store_headers() below already selects
> +         * the cacheable only headers using ap_cache_cacheable_headers_out(),
> +         * here we want to keep the original headers in r->headers_out and
> +         * forward all of them to the client, including non-cacheable ones).
>           */
> -        r->headers_out = ap_cache_cacheable_headers_out(r);
> +        r->headers_out = apr_table_overlay(r->pool, r->headers_out,
> +                                           r->err_headers_out);
> +        apr_table_clear(r->err_headers_out);
>
>          /* Merge in our cached headers.  However, keep any updated values. */
>          /* take output, overlay on top of cached */
>
>



-- 
Eric Covener
covener@gmail.com

Mime
View raw message