httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_cache with Cache-Control no-cache= or private=
Date Sun, 10 Mar 2013 00:55:42 GMT
On 04 Mar 2013, at 8:22 PM, ylavic dev <ylavic.dev@gmail.com> wrote:

> I've been working on a patch for mod_cache to deal (fully) with the response header Cache-Control
and the no-cache=<header> or private=<header> directives.
> This "feature" is mainly used with the Set-Cookie header, and allows the origin server
to control the caching of that particular header.
> 
> Although the code is already there to detect their usage with a header, mod_cache still
handle these directives as if no header was specified.
> That is, "stale entity causing revalidation" [by the origin server].
> 
> The RFC-2616 (14.9.1 What is Cacheable) says this about the no-cache=<header> directive
:
>       If the no-cache directive does specify one or more field-names,
>       then a cache MAY use the response to satisfy a subsequent request,
>       subject to any other restrictions on caching. However, the
>       specified field-name(s) MUST NOT be sent in the response to a
>       subsequent request without successful revalidation with the origin
>       server. This allows an origin server to prevent the re-use of
>       certain header fields in a response, while still allowing caching
>       of the rest of the response.
> For what I understand, mod_cache is allowed to serve its cached entity (though without
the specified header(s)).

I read this through again, this time having slept properly.

The way I read the spec, "the specified field-name(s) MUST NOT be sent in the response to
a subsequent request without successful revalidation with the origin server". What this means
is that if the specified field names are found to be present in the cached response, then
the origin server needs to be given the opportunity to update these fields through a conditional
request. In the current cache code, we return 0 meaning "this is stale, revalidate", and a
conditional request is sent to the origin. We hope the origin sends "304 Not Modified", with
updated headers corresponding to the fields.

If we were to follow this patch, it means that the first time we hit the URL, the client sees
the private/no-cache fields, but every cached response after will be treated as fresh with
the field missing. This breaks caching.

What you're trying to achieve needs to be handled by your origin server, which should support
conditional requests, and then send updated Set-Cookie headers along with the 304 Not Modified
responses. This way the body stays cached, but your Set-Cookie is updated on every hit.

Regards,
Graham
--


Mime
View raw message