replacing cache-control headers

[Ryan Malayter]

On Thu, Mar 11, 2010 at 9:47 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> This is expected behaviour.

Thank you for the explanation. It is easy to forget that nginx has a
declarative configuration language, not imperative. Sort of (order
does seem to matter in some cases).

>> Is there any way do do this using default nginx modules?
>
> You may try to do this with embedded perl, specifically perl_set.
> Something like this should work:
>
>    perl_set  $mycc  'sub {
>        return shift->variable("upstream_http_cache_control") || "no-cache";
>    }';

Very interesting. The English-language wiki says that this module is
still experimental, which makes me leery of introducing it to a
high-volume site (over 600 requests/sec at times). Is that information
outdated? I cannot seem to find a Russian-language equivalent to that
page, either on nginx.org or sysoev.ru. Would the Perl module
drastically slow things down?

Based on your first notes above about the execution order of rewrite
directives, I was able to come up with a workaround, using a separate
location. Since I know the URLs that set improper headers on the
back-end have a specific set of substrings, I was just able to make a
regex-based location for that ("location ~* ) which does the
proxy_hide_header cobined with add_header, while the previous
"location /" just passes the back-end's caching headers uinmodified.
This should work as long as we don't run across too many more URL
patterns that need "adjusting". Again I am a bit worried about
performance with this regex solution, but we are entering into a load
test cycle soon.

-- 
RPM