Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Set-Cookie header is injected into static content requests, breaking caching.
See original GitHub issueRight now, if LoginManager() is installed in a flask-app, it adds a set-cookie header to ALL requests, including static content.
This breaks (at least) Nginx reverse-proxy caching, as nginx disables caching if it sees a set-cookie header, even if the flask app itself returns the proper HTTP 304 for the relevant resource.
Realistically, setting cookies on static content is kind of silly anyways, and probably shouldn’t happen in the first place.
It’d be nice if flask-login only set cookies on things that actually can change.
Issue Analytics
- State:
- Created 8 years ago
- Comments:9 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@Garrett-R: you saved my day!
Wanted to mention I had this same issue and give the solution for future readers.
Turns out that if your app makes any call to
flask_login.current_user, then the Flask session will (unsurprisingly) be accessed. On any request where the session is accessed, Flask (surprisingly) will add theVary: cookieheader to the response (perhaps also theSet-Cookieheader, but it’s theVaryheader responsible for caching problems). Here was my solution.