<div dir="ltr">One way to alleviate, a bit, this problem is to make sure that a cookie is always set on the first request.<div><br></div><div>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.</div>

<div><br></div><div>E.g: </div><div><br></div><div>Let's say you are serving <a href="http://www.example.com/mylandingpage.html">www.example.com/mylandingpage.html</a></div><div>Have a script hosted at <a href="http://www.example.com/pixel.php">www.example.com/pixel.php</a> and add an <img /> tag pointing to it on all your pages.</div>

<div><br></div><div>Pixel.php contains:</div><div><div><font face="courier new, monospace">header("Content-type: image/gif");</font></div><div><font face="courier new, monospace">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));</font></div>

</div><div><br></div><div>mylandingpage.html:</div><div><font face="courier new, monospace"><body></font></div><div><font face="courier new, monospace">    <img src="//pixel.php" /></font></div><div>

<font face="courier new, monospace"></body></font></div><div><br></div><div>your .vcl file:</div><div><font face="courier new, monospace">sub vcl_recv()</font></div><div><font face="courier new, monospace">{</font></div>

<div><font face="courier new, monospace">    // Never cache the pixel... you wouldn't like your customers to share the same cookie.</font></div><div><font face="courier new, monospace">    if(req.url ~ "pixel.php")</font></div>

<div><font face="courier new, monospace">    { </font></div><div><font face="courier new, monospace">        return (pass);</font></div><div><font face="courier new, monospace">    }</font></div><div><font face="courier new, monospace">}</font></div>

<div><br></div><div>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.</div><div>

<br></div><div>-Hugues</div><div><a href="http://betabrand.com">betabrand.com</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 4:50 AM, Dridi Boukelmoune <span dir="ltr"><<a href="mailto:dridi.boukelmoune@zenika.com" target="_blank">dridi.boukelmoune@zenika.com</a>></span> wrote:<br>

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