I’m trying to add Cache-Control headers to an ill-behaved backend
application (that I don’t control). For many requests, the backend
sets Cache-Control headers with an empty value (an RFC violation, I
know, and a bug report has been filed, but resolution is likely going
to take months from the vendor). Nginx 0.7.62 using default Ubuntu
package from Karmic.
I need to avoid using the “more Headers” module if at all possible for
administrative reasons (standard packages are much easier to deal with
administratively and make life much easier during audits).
So, I am trying to use proxy_hide_header and variables to
conditionally set the header. The problem is that using
$upstream_http_cache_control in a “set” or “if” statement always seems
to evaluate to the empty string. However, I can add a customer header
which shows the value passed from the upstream correctly if is not
empty.
Here is the relevant portion of my config (I have tried many variants
of positive and negative logic, without success):
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_read_timeout 900;
proxy_redirect default;
proxy_hide_header Pragma;
proxy_hide_header Cache-Control;
set $mycc $upstream_http_cache_control;
if ($mycc = "") {
set $mycc "no-cache";
}
add_header "Cache-Control" $mycc;
add_header "X-Upstream-Cache-Control"
$upstream_http_cache_control;
add_header “X-Upstream-Expires” $upstream_http_expires;
}
With this configuration, I always get “Cache-Control: no-cache”
headers, even when “X-Upstream-Cache-Control” shows that the upstream
did pass a non-empty Cache-Control header. An Example response:
HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Thu, 11 Mar 2010 15:10:36 GMT
Content-Type: application/x-javascript
Connection: keep-alive
Content-Length: 10134
Last-Modified: Sun, 24 Jan 2010 12:05:44 GMT
Accept-Ranges: bytes
ETag: “166958eed9cca1:0”
Cache-Control: no-cache
X-Upstream-Cache-Control: max-age=900
Is there any way do do this using default nginx modules?
RPM
Hello!
On Thu, Mar 11, 2010 at 09:17:03AM -0600, Ryan M. wrote:
location / {
}
As rewrite module directives (“if”, “set”) are executed during
rewrite phase of request processing it will always see empty value
of $upstream_http_cache_control variable (it’s not yet available
as no headers got from upstream yet).
add_header "Cache-Control" $mycc;
add_header "X-Upstream-Cache-Control" $upstream_http_cache_control;
add_header "X-Upstream-Expires" $upstream_http_expires;
}
With this configuration, I always get “Cache-Control: no-cache”
headers, even when “X-Upstream-Cache-Control” shows that the upstream
did pass a non-empty Cache-Control header. An Example response:
This is expected behaviour.
[…]
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”;
}’;
Maxim D.
On Thu, Mar 11, 2010 at 9:47 AM, Maxim D. [email protected]
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