-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
fix: page cache saves Response data before running after filters #6282
fix: page cache saves Response data before running after filters #6282
Conversation
Since the issue affects the operation of the SecureHeaders filter, it seems to me that it would also be correct to return the Response in the SecureHeaders::after() method. |
What do you mean? |
@kenjis If we are targeting the implementation of PSR-15 in version 5, then it would be logical to prepare the codebase for the correct behavior. So that it doesn’t work out, as with legacy 3.x, when, with the transfer of the code base from 3.x to 4.x, the code started to work incorrectly or not as intended. But yes, within the framework of the current concept of the framework, my proposal does not make sense. |
@iRedds I got your point. But I think it is related not only SecureHeaders but also all after filters. We can't do anything in this PR. |
Response headers added by after filters will not be sent. Response body changes by after filters will be lost.
e514e5c
to
901860b
Compare
Added the upgrade guide. |
901860b
to
91f6f1c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few typos then looks good! Thanks for adding the explicit docs.
// Cache it without the performance metrics replaced | ||
// so that we can have live speed updates along the way. | ||
// Must be run after filters to preserve the Response headers. | ||
if (static::$cacheTTL > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you certain that 0
indicates "don't cache"? Sometimes it means "never expire".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, I see this was just moved from below!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few typos then looks good! Thanks for adding the explicit docs.
Co-authored-by: MGatner <mgatner@icloud.com>
Co-authored-by: MGatner <mgatner@icloud.com>
*/ | ||
public function run(?RouteCollectionInterface $routes = null, bool $returnResponse = false) | ||
{ | ||
if ($this->context === null) { | ||
throw new LogicException('Context must be set before run() is called. If you are upgrading from 4.1.x, you need to merge `public/index.php` and `spark` file from `vendor/codeigniter4/framework`.'); | ||
} | ||
|
||
static::$cacheTTL = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it means that cacheTTL
value is reset in every run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
$cacheTTL will be set by a Controller.
Description
Fixes #6281
The page cache saves Response data before running after filters.
So response headers added by after filters and response body changes by after filters will be lost.
Checklist: