this section is the only addition compared to#4627

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"

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

In practical terms, what should this mean to the user? I think it means that you're telling Varnish toyes be ok with caching requests that contain cookies. And so, as a user, you must be very careful tonot 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.

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

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

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

good idea. linked.

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 PRsymfony/symfony#6388 or issuesymfony/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.