-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable auto cache control of the Symfony SessionListener #1033
Conversation
Thank you @Toflar. |
Should we do this for everything? Or should we only do that for Contao requests? Also, I realize that this listener is in the contao-core bundle, so this is also applied to any regular Symfony application, not sure we can assume anything about caching and cookie whitelists there? |
I think it's not wrong in the core-bundle but it should probably check for |
…iable (see #1034) Description ----------- While debugging #1033 I noticed that we cannot configure the trace level of `HttpCache`. It absolutely makes no sense to bind that to `$this->isDebug` because in our case, this is always the case when we are in `dev` mode which again disables the HttpCache completely. So here we go, by setting `TRACE_LEVEL=full` the `Contao-Cache` header gives you a lot more insight into the fragment requests. Commits ------- 64fe068 Allow to configure the HttpCache trace level using an environment variable
…iable (see #1034) Description ----------- While debugging contao/contao#1033 I noticed that we cannot configure the trace level of `HttpCache`. It absolutely makes no sense to bind that to `$this->isDebug` because in our case, this is always the case when we are in `dev` mode which again disables the HttpCache completely. So here we go, by setting `TRACE_LEVEL=full` the `Contao-Cache` header gives you a lot more insight into the fragment requests. Commits ------- 64fe0685 Allow to configure the HttpCache trace level using an environment variable
yes thats what I meant |
Add an issue then so we don't forget about it. |
See #1079 |
Fixes #1028.
In fact, we don't need the default behaviour of Symfony because we qualify for "advanced usage" and our listener already correctly handles making responses private if needed.
I thought we need session stacking but that's not required because the SessionListener of SF correctly closes the session during
kernel.finish_request
which will cause our listener to correctly determine that the session was not started yet during the nextkernel.response
.