<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif"}
span.emailstyle17
{font-family:"Calibri","sans-serif";
color:windowtext}
span.EmailStyle18
{font-family:"Calibri","sans-serif";
color:#1F497D}
span.EmailStyle19
{font-family:"Calibri","sans-serif";
color:#1F497D}
span.BalloonTextChar
{font-family:"Tahoma","sans-serif"}
.MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
{}
-->
</style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Raul,</span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for the suggestion. That sounds like a much better solution and doesn’t rely on the browser issuing a separate request to set cookies.</span></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="color:#1F497D">When you say that it would require the parent request to block does that mean that Varnish starts sending the response from the cache until it hits an esi tag, at which point it waits for the included content
from the backend but then carries on sending the content after that?</span></p>
<p class="MsoNormal"><span style="color:#1F497D">Most of our dynamic content that is included via ESI is right at the top of the page (e.g. mini-basket, welcome ‘user’ message etc.) so it’s going to be waiting for that whatever but I can see why for ESI lower
down it wouldn’t be optimal.</span></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks again,</span></p>
<p class="MsoNormal"><span style="color:#1F497D">Andrew</span></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif""> Rangel, Raul [mailto:Raul.Rangel@disney.com]
<br>
<b>Sent:</b> 10 April 2013 15:20<br>
<b>To:</b> Fletcher Andrew; 'varnish-misc@varnish-cache.org'<br>
<b>Subject:</b> RE: setting cookies from within esi included content</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I don’t think merging headers is on the road map. It would require the parent request block until all the ESIs have loaded which would be bad if you have a bunch of ESIs below the fold.</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">One work around that would work for your cookie issue is to make the parent page be the page that sends the Set-Cookie header and then have the body of it only include an esi.</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">i.e)</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Set-Cookie: abc=123</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><esi:include href=”/full_page” /></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">This way you can cache the /full_page ESI object but still set unique cookies for each user. We make heavy use of this technique and have not had any issues with it.</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Raul</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">
<a href="mailto:varnish-misc-bounces@varnish-cache.org">varnish-misc-bounces@varnish-cache.org</a> [<a href="mailto:varnish-misc-bounces@varnish-cache.org">mailto:varnish-misc-bounces@varnish-cache.org</a>]
<b>On Behalf Of </b>Fletcher Andrew<br>
<b>Sent:</b> Wednesday, April 10, 2013 4:53 AM<br>
<b>To:</b> <a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<b>Subject:</b> setting cookies from within esi included content</span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<div>
<p class="MsoNormal">Hi,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I’m using Varnish to cache a shopping site that has a mini-basket on every page. I’m caching the parent page and including the basket via ESI so that it is never cached and always gets retrieved from the backend.</p>
<p class="MsoNormal">The mini basket is what sets the session id cookie but Varnish’s ESI implementation doesn’t merge the response headers of the included page with the parent before sending back to the browser.</p>
<p class="MsoNormal">Ideally what I’d like is to cache the parent page without any session id cookies, retrieve that from the cache, retrieve the included content and add the Set-Cookie headers of the included response to the main/parent response before delivering
to the browser.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Is there a roadmap for Varnish to add support for merging cookies from included responses?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">As a workaround I’m including a file in the page (as a css file but could be 1px image, js file etc) that is never cached by Varnish (sets Cache-Control: max-age=0) and returns the required Set-Cookie header for the session id cookie.</p>
<p class="MsoNormal">So the browser requests a page from Varnish, loads the resources of the page (the first of which is my special css) and sets the session id cookie. On subsequent requests it sends the cookie in the request which gets passed to the ESI request
for the mini-basket and the correct content is included into the page before being passed back to the browser.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Can anyone see any problems with this workaround?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It appears to be working well for us at the moment, however I can see it creating multiple redundant sessions. The first request includes the basket via ESI, which creates a new session (that is never used again because the session id is
not passed back to the browser) and then the browser makes another request for cookies.css that creates another new session (which is used from then on)</p>
<p class="MsoNormal">I’m also concerned that some browsers and other proxy servers may not honour the Cache-Control header and attempt to always cache my cookies.css file.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks for any input,</p>
<p class="MsoNormal">Andrew</p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt; font-family:"Times New Roman","serif""> </span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt; font-family:"Times New Roman","serif"">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:7.5pt; font-family:"Arial","sans-serif"; color:gray"><br>
This is an electronic communication from Reply Limited, any opinions expressed in this email are those of the individual and not necessarily those of Reply Limited. The information in this email and any attachments is confidential and may be subject to legal
professional privilege. it is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorised
to, and must not, read, copy, distribute, use or retain this message or any part of it. At present the integrity of e-mail across the internet cannot be guaranteed and message and documents sent via this medium are potentially at risk. Please note that neither
the sender nor Reply Limited accepts any responsibility for viruses and it is your responsibility to scan any attachments. All liability is excluded to the extent permitted by the law for any claims arising from the use of this medium by Reply Limited.<br>
<br>
Registered address: Reply Ltd, 38 Grosvenor Gardens, London, SW1W 0EB [Registered in England and Wales No: 3847202]. VAT No: 742468814.</span><span style="font-size:12.0pt; font-family:"Times New Roman","serif""></span></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This is an electronic communication from Reply Limited, any opinions expressed in this email are those of the individual and not necessarily those of Reply Limited. The information in this email and any attachments is confidential and may be subject to legal
professional privilege. it is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorised
to, and must not, read, copy, distribute, use or retain this message or any part of it. At present the integrity of e-mail across the internet cannot be guaranteed and message and documents sent via this medium are potentially at risk. Please note that neither
the sender nor Reply Limited accepts any responsibility for viruses and it is your responsibility to scan any attachments. All liability is excluded to the extent permitted by the law for any claims arising from the use of this medium by Reply Limited.<br>
<br>
Registered address: Reply Ltd, 38 Grosvenor Gardens, London, SW1W 0EB [Registered in England and Wales No: 3847202]. VAT No: 742468814.<br>
<br>
</font>
</body>
</html>