Luck cache does not cache PHP with sessions. If the backend has not changed TTL

Question

I am new to Varnish Cache and am wondering. I hope I can help.

I have a very simple and basic setup, but it does not work, as I understand it, it should for some reason.

This is because Varnish does not cache PHP pages that use cookies.

Here is my setup:

1) For my default.vcl, I have a simple backend

backend default { .host = "127.0.0.1"; .port = "80"; } 

2) I have a simple PHP file that has only two lines:

 session_start(); echo time(); 

3) When I call this page, it doesn’t cache correctly since I did not add vcl to the required rules

4)

So, according to my understanding of the documentation, I add in these two rules

 sub vcl_recv { unset req.http.Cookie; return (lookup); } sub vcl_fetch { unset beresp.http.Set-Cookie; return(deliver); } 

5) The PHP page will still not cache. I see that the Set-Cookie header has been removed since I am using FireBug in FireFox.

It is only if I add this to sub vcl_fetch that PHP will cache:

 set beresp.ttl = 24h; 

My question is, is this correct?

I did not think that I would need to change the ttl of the backend response. I thought that just disable cookies in and supersede PHP w / session for caching.

My full default vcl:

 backend default { .host = "127.0.0.1"; .port = "80"; } sub vcl_recv { unset req.http.Cookie; return (lookup); } sub vcl_fetch { unset beresp.http.Set-Cookie; set beresp.ttl = 24h; return(deliver); } 

My launch command:

 varnishd -f /etc/varnish/default.vcl -s malloc,128M -T 127.0.0.1:2000 -a 0.0.0.0:8080 

URL I call:

 http://vbox.local:8080/varnish-tests/index.php 

My index.php file has only:

 <?php session_start(); echo time(); 

I would like to ask the community if this looks right or if I am wrong. In fact, I'm just not sure why to add beresp.ttl = 24h to finally have the page cache in varnish.

I thought that I would not need it.

Any advice is greatly appreciated.

Thanks!

Sincerely.

Answer 1

The varnish will obey the response caching headers. PHP will send cache control headers so as not to cache the response with deafult

 Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma:no-cache 

You need to disable these headers, otherwise the varnish will obey and, thus, does not cache the page. To disable them, just call session_cache_limiter () with an empty string

 session_cache_limiter(''); header("Cache-Control: public, s-maxage=60"); session_start(); 

You can then add a header to set the cache control to public. Using the three lines above will allow caching.

Answer 2

As ZoFreX said, this is possible due to your Cache-Control or Expires header.

Also note that this rule is a bit dangerous:

 sub vcl_recv { unset req.http.Cookie; return (lookup); } sub vcl_fetch { unset beresp.http.Set-Cookie; return(deliver); } 

If your server sends cookies, perhaps because you need them, at least for sessions. This rule will completely disable session management for your application server.

Depending on why you use sessions, you may not be able to cache every part of your content (e.g. user-generated content).

Answer 3

You should look very carefully at the headers that PHP sends to the varnish (for example, by accessing your server directly, and not through varnishd). If the headers say that the content cannot be cached, it will not. If they do not say that they can be cached, it will not - and I suspect that is why the varnish only caches if you manually set ttl, because the headers do not have "expire" or "maximum age".

Answer 4

The easiest way to get a varnish cached response is to add a cache control header.

PHP:

 header('Cache-Control: public, s-maxage=60'); 

will say that the varnish will cache the response for 60 seconds.

Answer 5

I had the same problem. When you execute session_start, it seems like PHP notices that the page is potentially dynamic and helps reset cache control headers:

 Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma:no-cache 

Varnish's default configuration obeys these caching directives sent by apache / php, which means that they will not cache these pages. I'm not sure that 100% can override the default configuration, but only to expand it.

The workaround I used was to reset the Cache-Control headers, but note that this needs to be done after session_start has changed them. I have not tested whether this is also necessary after session_write_close, but is better safe than sorry.