Warn that NativeSessionStorage alters session.cache_limiter #4710
Conversation
| constructor sets ``session.cache_limiter`` to ``""``. If you rely on native sessions to manage cache | ||
| headers, you *must* at least pass this option to the constructor. | ||
|
|
||
| Example usage:: |
There was a problem hiding this comment.
Tried to nest code into a note, not sure if this will work.
There was a problem hiding this comment.
you have to add 2 more spaces in the indent (the new base is the 4 spaces indent of the note directive, to create a code block, you have to indent with 4 spaces from the base, so 4 + 4 = 8).
mrclay
changed the title
| @@ -102,6 +102,20 @@ method. | |||
|
|
|||
| For the sake of clarity, some key options are explained in this documentation. | |||
|
|
|||
| .. note:: | |||
There was a problem hiding this comment.
wouldn't a caution fit better here?
|
Thanks. I can make those changes. For a future version I wonder if it would be better to make the cache_limiter option required in the constructor or just don't change it. The principle of least surprise would suggest that constructing the object should not (silently) change a very important behavior of Sessions. |
|
i think this is really important, altering any kind of global in a service must become a part of the documentation. |
|
I've expanded my PR to a section on cache limiting (with a caution) which I think will be clearer. |
|
Replaced by #4728. Apologies for the churn. |
We're implementing HttpFoundation (by itself) to replace our native session implementation and noticed that NativeSessionStorage eliminates the global session.cache_limiter value. I understand why it must do this, but users should be warned that the default usage prescribed in the manual will cause all pages to be sent with no cache-busting headers.
/cc @Drak