Passing cookies to ESI includes

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.

E.g:

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

Pixel.php contains:
header("Content-type: image/gif");
sprintf
("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c",71,73,70,56,57,97,1,0,1,0,128,255,0,192,192,192,0,0,0,33,249,4,1,0,0,0,0,44,0,0,0,0,1,0,1,0,0,2,2,68,1,0,59));

mylandingpage.html:
<body>
    <img src="//pixel.php" />
</body>

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.

-Hugues
betabrand.com

On Wed, Jul 3, 2013 at 4:50 AM, Dridi Boukelmoune <
dridi.boukelmoune at zenika.com> 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 varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20130813/2f0d6262/attachment.html>