<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.emailstyle17
{mso-style-name:emailstyle17;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span 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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span 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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>i.e)<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Set-Cookie: abc=123<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><esi:include href=”/full_page” /><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span 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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Raul<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> varnish-misc-bounces@varnish-cache.org [mailto:varnish-misc-bounces@varnish-cache.org] <b>On Behalf Of </b>Fletcher Andrew<br><b>Sent:</b> Wednesday, April 10, 2013 4:53 AM<br><b>To:</b> varnish-misc@varnish-cache.org<br><b>Subject:</b> setting cookies from within esi included content<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span lang=EN-GB>Hi,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Is there a roadmap for Varnish to add support for merging cookies from included responses?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Can anyone see any problems with this workaround?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Thanks for any input,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Andrew<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-GB style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p><div class=MsoNormal align=center style='text-align:center'><span lang=EN-GB 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 lang=EN-GB 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 lang=EN-GB style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p></div></body></html>