How to adjust Cache-Control for SSI-including entities

Server NGINX
1

Hi,

[apologies if this has been asked lots of times before, but searches
really did not turn up anything]

I am using nginx with SSI enabled to assemble pages and page-fragments
from upstream servers.

upstream U1 produces the main page (the one containing SSI include
directives) and wants nginx to cache its response (the page with the
unresolved SSI include directives). Thus U1 sends the main page with
Cache-Control: max-age=60.

The includes come from upstream U2 and are also cacheable from the POV
of U2, hence U2 adds a max-age for those. The max-age could be less than
60 or more than 60.

What I want nginx to do is to cache the upstream response for the main
page and also cache the upstream responses for the includes - which
nginx does as the debug log suggests.

In addition I of course want nginx to strip/adjust the Cache-Control /
max-age when the assembled page is sent to the client.

Unfortunately nginx seems to simply copy the max-age of the main page
upstream response and send it to the client - which is obviously
misleading information since the cacheabilty of the response is unknown
or the lowest max-age of all includes.

Can anyone help me on how I get nginx to at least remove the misleading
Cache-Control header?

ssi_last_modified is related and yields the correct default behavior:
http://nginx.org/en/docs/http/ngx_http_ssi_module.html#ssi_last_modified

Jan

2

On Mon, Jan 19, 2015 at 08:44:33PM +0100, Jan A. wrote:

Hi there,

upstream U1 produces the main page (the one containing SSI include directives)
and wants nginx to cache its response (the page with the unresolved SSI include
directives). Thus U1 sends the main page with Cache-Control: max-age=60.

In addition I of course want nginx to strip/adjust the Cache-Control / max-age
when the assembled page is sent to the client.

Completely untested, but, depending on how you connect to upstream, does
“proxy_hide_header” or “proxy_ignore_headers” do what you want?

f

Francis D. [email protected]

3

Francis,

thanks a lot;

proxy_hide_header

does the trick. However, it still feels a bit brute-force.

Hence, if there are other solutions, I would be curious to know.

Meanwhile, hide gets me going.

Jan

4

Jan A. Wrote:

Francis,

thanks a lot;

proxy_hide_header

does the trick. However, it still feels a bit brute-force.

Hence, if there are other solutions, I would be curious to know.

With Lua you could test to see which header has the least expiry time
and
pass only that one.

Posted at Nginx Forum:

5

On 19 Jan 2015, at 21:38, Francis D. [email protected] wrote:

On Mon, Jan 19, 2015 at 08:44:33PM +0100, Jan A. wrote:

Hi there,

upstream U1 produces the main page (the one containing SSI include directives)
and wants nginx to cache its response (the page with the unresolved SSI include
directives). Thus U1 sends the main page with Cache-Control: max-age=60.

In addition I of course want nginx to strip/adjust the Cache-Control / max-age
when the assembled page is sent to the client.

Completely untested, but, depending on how you connect to upstream, does
“proxy_hide_header” or “proxy_ignore_headers” do what you want?

Do you have any idea, how I can then best re-add the header? The case
came up that clients need an explicit Cache-Control: no-cache (to ensure
reload of the page when hitting the back button )

Jan

6

On Tue, Jan 20, 2015 at 11:46:36AM +0100, Jan A. wrote:

On 19 Jan 2015, at 21:38, Francis D. [email protected] wrote:

Completely untested, but, depending on how you connect to upstream, does
“proxy_hide_header” or “proxy_ignore_headers” do what you want?

Do you have any idea, how I can then best re-add the header? The case came up
that clients need an explicit Cache-Control: no-cache (to ensure reload of the
page when hitting the back button …)

In general, Module ngx_http_headers_module

But for this specific header, perhaps “expires” on the same page is more
useful.

f

Francis D. [email protected]