Incomplete cookbook entry about Varnish + ESI ?

[greg0ire]

I was struggling with ESI today, when I stumbled upon this SO question.
The cookbook entry about ESI doesn't talk about session cookies, and it seems that they prevent cache lookups (when in the request) and caching (when in the response) (at least when you start from the default VCL configuration and apply the changes documented in the cookbook entry).
Following the cookbook entry leads to a working html page, but with no caching. Shouldn't this be documented ?

[weaverryan]

I agree - this is incomplete as it is now - someone needs to really go through a Varnish setup with Symfony and outline all the steps and things to watch out for. We don't need to rewrite any Varnish docs, we just need a guide on how to navigate through Varnish and Symfony (including details about cookies, recommendations, and links to Varnish docs).

A big +1 for this.

[greg0ire]

The new docs should probably answer the following questions :

1. When developing, should one use the built-in reverse proxy or Varnish?
   1. If yes, how can one make sure this reverse proxy is used only in the development environment ?
   2. If not, what program should listen on which port ? How should SSL be dealt with ?
2. How should Varnish decide to remove the cookies ?
3. How can one check that Varnish is in use ?

My answers to these questions (open for discussion, may be completely wrong) :

1. I think the reverse proxy should be used when trying to setup caching in the application, and once it works, Varnish should be used, so that the dev environment stays similar to the production environment.
   1. No idea.
   2. I think Varnish should listen on port 80, and the webserver behind it on whatever you choose. I don't know how to deal with SSL on a development machine though. That would probably require setting up haproxy before it like we do on our production machine.
2. If you use sonata page bundle, the url pattern is a good thing to look at. Otherwise, I think the presence of a Shared-Max-Age header is a good indicator that a page is meant to be cached.
3. One can look at their web server access logs, and if there are less requests after the first request, it probably works.

[lyrixx]

I think the presence of a Shared-Max-Age header is a good indicator that a page is meant to be cached.

It's exactly what I do in my varnish conf. If the response has a smax-age, I do remove cookie.

But we can not document that. It's too specific and too important. One can mess the conf and break the security layer. People should understand how varnish + http + symfony work. And then they can tweak the config.

Anyway, if there is no cookie in the response, varnish is able to cache...

[greg0ire]

But we can not document that.

@lyrixx : so what would you recommend instead ? Links to the Varnish documentation about cookies, and nothing more, so that people figure something out by themselves ?

[lyrixx]

Good idea ;)

[dbu]

is there no more elegant solution about the cookie problem than unsetting it in varnish? can't symfony determine if it needs a session or not?

(i asked the same question in #4141 - maybe you can give input there as well. with regard to #4175 i hope to review the caching documentation and propose improvements)