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
Prevent caching of tracker in proxies #12730
Conversation
Thanks for the PR @c960657 👍 Before we can merge, could you please add some test(s) in tests/PHPUnit/System/TrackerResponseTest.php to ensure we don't regress this in the future? |
3c1f426
to
01501de
Compare
I have added some tests. Instead of using These methods |
I changed it to use |
4b64fca
to
e83eb4f
Compare
Varnish default config violates the HTTP spec in this respect.
37e7265
to
1d58c9f
Compare
Code looks good to me. FYI @tsteur this PR deprecates some custom asserts, requires your approval. (Don't think they're actually that useful, but just want to make sure no one else finds them useful.) |
* Prevent caching of tracker in proxies * Also send Cache-Control with 204 responses. Varnish default config violates the HTTP spec in this respect. * Test Cache-Control header * Update changelog * Use no-store instead of no-cache
When Piwik is running behind a reverse proxy (e.g. for load-balancing), hits to
piwik.php
may be cached in the proxy.This has two problems:
This PR adds adds a Cache-Control directive that prevents any caching of the request. For POST requests
and 204 requests, caching is already prohibited according to the HTTP spec (unless explicitly permitted by Cache-Control headers), so I do not send the header for these requests in order to save bytes over the wire.Even though 204 responses are not cacheable without an explicit Cache-Control header, according to RFC 7231, section 6.1, the default Varnish configuration does not respect this, so
Cache-Control: private
is also sent for 204 responses.