setting cookies from within esi included content

[Rangel, Raul]

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.

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.

i.e)
Set-Cookie: abc=123

<esi:include href="/full_page" />

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.

Raul

From: varnish-misc-bounces at varnish-cache.org [mailto:varnish-misc-bounces at varnish-cache.org] On Behalf Of Fletcher Andrew
Sent: Wednesday, April 10, 2013 4:53 AM
To: varnish-misc at varnish-cache.org
Subject: setting cookies from within esi included content

Hi,

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.
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.
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.

Is there a roadmap for Varnish to add support for merging cookies from included responses?

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.
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.

Can anyone see any problems with this workaround?

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)
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.

Thanks for any input,
Andrew

________________________________

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.

Registered address: Reply Ltd, 38 Grosvenor Gardens, London, SW1W 0EB [Registered in England and Wales No: 3847202]. VAT No: 742468814.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20130410/6fb8793f/attachment.html>