Varnish cookbook session cookie handling #4628

dbu · 2014-12-11T14:34:21Z

Q	A
Doc fix?	yes
New docs?	no
Applies to	all
Fixed tickets	#3881

This builds on top of #4627 but i wanted to keep it separate as there are open questions in here.

dbu · 2014-12-11T14:34:48Z

cookbook/cache/varnish.rst

+If this headers are not set properly, Symfony will append the port where the
+PHP application is running, e.g. ``8080``, when generating absolute URLs.
+
+Session Cookies and Caching


this section is the only addition compared to #4627

timglabisch · 2014-12-12T07:58:02Z

cookbook/cache/varnish.rst

+.. index::
+    single: Varnish; configuration
+
+Make Symfony Trust the Reverse Proxy


most headlines are in "Gerund", so i am 👎 to change this.

wait, please comment on #4627 for this

the only new section compared to #4627 in here is "Session Cookies and Caching"

stof · 2014-12-16T11:01:55Z

cookbook/cache/varnish.rst

+not. When you use the Symfony reverse proxy, you don't need to do anything.
+But to make Varnish instead of Symfony resolve the ESI tags, you need some
+configuration in Varnish. Symfony uses the ``Surrogate-Capability`` header
+from the (`Edge Architecture`_) described by Akamai .


why are you putting braces here ?

the only new section compared to #4627 in here is "Session Cookies and Caching"

but you are right that this is weird. i just reformatted this section, did not change the content. but will have another look into this.

because it was there before. bad excuse. fixed.

in #4627, that is

weaverryan · 2014-12-22T21:43:38Z

cookbook/cache/varnish.rst

+            /* Force cache lookup for requests with cookies */
+            return (lookup);
+        }
+    }


In practical terms, what should this mean to the user? I think it means that you're telling Varnish to yes be ok with caching requests that contain cookies. And so, as a user, you must be very careful to not rely on the session for any parts of your page where you return caching headers. If you violate this rule, then you will cache something with - for example - a user's username in it.

Is this about right? I want to walk the user through this as much as possible. For me, it seems that you should be (as you elude to here) identifying which portions of your page need the session, isolating them into non-cached ESI fragments, then caching the whole page (or doing a complete opposite strategy where you isolate non-session-needing heavy pieces, then don't cache the whole page).

The point is, this is non-trivial, so perhaps we need to walk them through a bit more tutorial-styled.

Actually, I still mean everything I said, but most of what I said should be in the book. I still think we can add a few more details, like those I have in my first paragraph.

i tried to make this more explicit, and also added a warning at the end of the section.

timglabisch · 2014-12-26T18:54:55Z

cookbook/cache/varnish.rst

+
+    Be sure to test your setup. If you do not ``Vary`` content that depends on
+    the session, users will see content from somebody else. If you ``Vary`` too
+    much, the Varnish cache will be filled with duplicate content for every


i dont think we should suggest varying based on cookies. this is just useable if you vary on flags (Terms, Users Age, ...)

i disagree. assume i have one url /_fragment/user/toolbar that renders the user name into every page. the rest of the content does not vary on cookie, but this one url does. and its embedded with ESI into every page. then we would want to cache this url as a variant for every single user to avoid reloading it all the time. once you log out, your session will be destroyed, meaning the session cookie changes and thus you don't see your username anymore.

obviously, you need to clean the cookie string for this to work, you don't want any js cookies irrelevant for the backend in here.

you could also store the username in a cookie / localstorage or something else to print it. from my point of view storing user specific content in the reverse proxy can be a good idea but most time you should try to avoid it. people could think it's a good idea to mess up the cache with a Vary on the Cookie. This issue is hard to find for newbies because most times, if they test they use the same cookie. Why not creating a advanced cookbook where we explain how to cache based on Cookies (Javascript), Cookies + Vary (Varnish), Localstorage, ....

dbu · 2014-12-28T08:22:33Z

@timglabisch copied your comment from a line that was now changed:

you could also store the username in a cookie / localstorage or something else to print it. from my point of view storing user specific content in the reverse proxy can be a good idea but most time you should try to avoid it. people could think it's a good idea to mess up the cache with a Vary on the Cookie. This issue is hard to find for newbies because most times, if they test they use the same cookie. Why not creating a advanced cookbook where we explain how to cache based on Cookies (Javascript), Cookies + Vary (Varnish), Localstorage, ....

the problem is that saying to cache even when there are cookies is pretty dangerous. but stripping all cookies including the session is a really good trick to break your knees...

this somewhat touches #4661 - somebody could either expand that one or add a separate receipie to the cookbook. i do not plan to do that right now (its been a while that i even worked with a html frontend and varnish, currently i am caching APIs :-) ). so what do we do? should i just drop the bit about ESI and vary on cookie? or mention it in 5 words and let people wonder how it actually can be done?

timglabisch · 2014-12-28T13:30:28Z

cookbook/cache/varnish.rst

@@ -60,6 +60,87 @@ If the ``X-Forwarded-Port`` header is not set correctly, Symfony will append
 the port where the PHP application is running when generating absolute URLs,
 e.g. ``http://example.com:8080/my/path``.

+Session Cookies and Caching


why not dropping the word "Session", it's for all Cookies.

timglabisch · 2014-12-29T16:22:02Z

my problem is that this PR suggests that using vary on the cookie header is the way to go. i would do a lot to avoid caching based on a user specific cookie, for me this is more like an antipattern that can work in some situations. Don't get me wrong, the PR provides a useable way, but i would like the reader to know that there are alternative ways to solve such problems. if the page could be cached based on a user specific cookie, most time it's not worth to be cached at all. if you're running a huge varnish cluster without stickiness you even can hurt the performance. I am 👍 with this PR but would love to see a hint that there are a lot of caching strategies with different advantages and disadvantages.

dbu · 2014-12-31T12:14:51Z

i removed the part about vary on cookie as it is indeed very specific. this is now rather short and just giving some pointers and basic considerations. the rest of the question is not varnish specific and should go into #4141, #4661 and possibly some features / doc in FOSHttpCacheBundle

stof · 2014-12-31T14:10:33Z

cookbook/cache/varnish.rst

+    If content is not different for every user, but depends on the roles of a
+    user, a solution is to separate the cache per group. This pattern is
+    implemented and explained by the FOSHttpCacheBundle_ under the name
+    *User Context*.


what about linking directly to the relevant page of the bundle documentation ?

good idea. linked.

* link user context to relevant section of the doc * better explain what we achieve with cleaning the cookies

dbu · 2015-01-18T10:57:24Z

cookbook/cache/varnish.rst

+start a session when actually needed, and clear the session when it is no
+longer needed. Alternatively, you can look into :doc:`../cache/form_csrf_caching`.
+
+.. todo link "only start a session when actually needed" to cookbook/session/avoid_session_start once https://github.com/symfony/symfony-docs/pull/4661 is merged


eliminated one of the TODOs . #4661 is still not merged, so i can't link to that. can we wrap those up?

I think #4661 is kind of blocked because of the difficulty of the topic - you have 1 open question and 1 todo on that issue that I can't answer without some time to look into things.

As an aside, for me, this smells like a bug or missing feature in Symfony. I think the PR symfony/symfony#6388 or issue symfony/symfony#6036 need to be finally pushed along - the functionality just isn't right. Of course, that's an even bigger task.

okay. can we get this PR merged then? looks like the session start issue is a potentially long story.

or do you not want todos in the doc code? should we create a new issue to remind us that when #4661 is merged we add a reference in this section of the doc.

weaverryan · 2015-01-30T02:50:06Z

Yep, we'll keep that todo in there for now. Thanks for giving these sections much-needed updates. Cheers!

This PR was merged into the 2.3 branch. Discussion ---------- Varnish cookbook session cookie handling | Q | A | ------------- | --- | Doc fix? | yes | New docs? | no | Applies to | all | Fixed tickets | #3881 This builds on top of #4627 but i wanted to keep it separate as there are open questions in here. Commits ------- b294b24 cleanup from feedback 7a4dafc remove part about vary on cookie c88ad32 explain how to work with cookies and sessions when caching

dbu reviewed Dec 11, 2014
View reviewed changes

xabbuh added the Status: Needs Work label Dec 11, 2014

timglabisch reviewed Dec 12, 2014
View reviewed changes

xabbuh mentioned this pull request Dec 12, 2014

Advanced exmple of Varnish settings #1505

Closed

stof reviewed Dec 16, 2014
View reviewed changes

dbu mentioned this pull request Dec 22, 2014

Rewrite the varnish cookbook article #4627

Merged

weaverryan reviewed Dec 22, 2014
View reviewed changes

dbu changed the title ~~[WIP] Varnish cookbook session cookie handling~~ Varnish cookbook session cookie handling Dec 25, 2014

timglabisch reviewed Dec 26, 2014
View reviewed changes

timglabisch reviewed Dec 28, 2014
View reviewed changes

dbu mentioned this pull request Dec 31, 2014

Notes about caching pages with a CSRF Form #4141

Merged

stof reviewed Dec 31, 2014
View reviewed changes

dbu added 3 commits January 18, 2015 11:53

explain how to work with cookies and sessions when caching

c88ad32

remove part about vary on cookie

7a4dafc

cleanup from feedback

b294b24

* link user context to relevant section of the doc * better explain what we achieve with cleaning the cookies

dbu reviewed Jan 18, 2015
View reviewed changes

weaverryan merged commit b294b24 into symfony:2.3 Jan 30, 2015

dbu deleted the varnish-cookbook-session-cookie-handling branch February 20, 2015 15:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Varnish cookbook session cookie handling #4628

Varnish cookbook session cookie handling #4628

dbu commented Dec 11, 2014

dbu Dec 11, 2014

timglabisch Dec 12, 2014

dbu Dec 12, 2014

dbu Dec 12, 2014

stof Dec 16, 2014

dbu Dec 16, 2014

dbu Dec 18, 2014

dbu Dec 18, 2014

weaverryan Dec 22, 2014

weaverryan Dec 22, 2014

dbu Dec 25, 2014

timglabisch Dec 26, 2014

dbu Dec 27, 2014

timglabisch Dec 27, 2014

dbu commented Dec 28, 2014

timglabisch Dec 28, 2014

timglabisch commented Dec 29, 2014

dbu commented Dec 31, 2014

stof Dec 31, 2014

dbu Jan 1, 2015

dbu Jan 18, 2015

weaverryan Jan 23, 2015

dbu Jan 27, 2015

weaverryan commented Jan 30, 2015

Varnish cookbook session cookie handling #4628

Varnish cookbook session cookie handling #4628

Conversation

dbu commented Dec 11, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbu commented Dec 28, 2014

Choose a reason for hiding this comment

timglabisch commented Dec 29, 2014

dbu commented Dec 31, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weaverryan commented Jan 30, 2015