Passing cookies to ESI includes

Hugues Alary hugues at
Wed Aug 14 06:09:56 CEST 2013

One way to alleviate, a bit, this problem is to make sure that a cookie is
always set on the first request.

To do that, you can include on every page a fake pixel image that will hit
a page that will return a response with a Set-Cookie header.


Let's say you are serving
Have a script hosted at and add an <img /> tag
pointing to it on all your pages.

Pixel.php contains:
header("Content-type: image/gif");

    <img src="//pixel.php" />

your .vcl file:
sub vcl_recv()
    // Never cache the pixel... you wouldn't like your customers to share
the same cookie.
    if(req.url ~ "pixel.php")
        return (pass);

I'm however not sure this will make the *very* *first* request not create
garbage sessions, but it will prevent your customer from not having any
cookie until they hit a non-cached page.


On Wed, Jul 3, 2013 at 4:50 AM, Dridi Boukelmoune <
dridi.boukelmoune at> wrote:

> Hi all,
> I hope someone can help me with this ESI problem I have with one of my
> clients.
> One of the applications here use Varnish in front of two backends, and
> we see a lot of session garbage allocated because of ESI not passing
> cookies back-and-forth.
> The two backends in a nutshell:
> - front office (drupal cms)
> - back office (java webapp, connected to other services of the company)
> For the sake of simplicity, assume the front and back offices send
> respectively PHPSESSID and JSESSIONID cookies.
> The setup is also twisted, since you can actually access to both front
> and back offices (varnish does the routing) and each can esi:include
> fragments from the other. I haven't got through the 5 whys with the
> team yet...
> The worst case scenario:
> - Access to the front office without any cookie
> => drupal adds a set-cookie header for PHPSESSID
> => varnish finds N esi:include tags
> ==> the back office creates N different JSESSIONID set-cookie headers
> (one per request)
> It means N wasted sessions on the back office since none of the
> cookies will be retrieved by the user agent. And this will happen
> until you actually hit a page directly on the back office (with a
> shiny JSESSIONID).
> The ideal solution:
> - Access to the front office without any cookie
> => drupal adds a set-cookie header for PHPSESSID
> => varnish finds N esi:include tags
> ==> varnish fires the first esi request
> ===> the backoffice adds a set-cookie header for JSESSIONID
> ===> varnish adds the JSESSIONID cookie to the existing set-cookie header
> ===> varnish adds the JSESSIONID cookie header to the next requests
> ==> varnish fires the other N-1 esi requests with the JSESSIONID cookie
> ===> the back office doesn't create additional sessions
> ==> varnish answers with both PHPSESSID and JSESSIONID cookies
> => champagne \o/
> I'm open to any kind of solution, including (no pun intended) inline C
> or open source vmods. Any help appreciated :)
> One more thing:
> I'm aware of libvmod-header, which solves the (implicit) multiple
> Set-Cookie headers issue, but doesn't help cross the ESI boundaries.
> Best Regards,
> Dridi
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the varnish-misc mailing list