-
-
Notifications
You must be signed in to change notification settings - Fork 600
[5.x] Set etags #11441
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
[5.x] Set etags #11441
Conversation
jasonvarga
left a comment
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.
I guess the etag is fine, but the last modified doesn't quite seem right. I don't know if we should be adding that.
The entry may have been last modified on that date, but the response may differ after that depending on a bunch of factors. Relationships (other entries, terms, assets, etc), dynamic tags, etc.
|
https://datatracker.ietf.org/doc/html/rfc7232#section-2.2.1
You're right. if we cannot determine a reasonable updated at value from the data we might not want to set it. While not a problem for the target of this header, being search engines. Which are only interested in large changes and simply determine the crawl interval based on the last modified header. I will update the PR once I have access to a PC |
|
I've removed the last-modified header and left the Etag in |
This change will add the etag header to every page response, allowing browsers and more to determine wether their file is still fresh.
And in case of an updated_at being available set the last modified header.
see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified
This would allow crawlers to adjust their crawl frequency on pages not often updated.
And allow browsers to determine wether their page is fresh.
However if the browser supports an etag that will be used instead.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#heuristic_caching:~:text=Note%3A%20RFC9110%20prefers%20that%20servers%20send%20both%20ETag%20and%20Last%2DModified
This PR differs a lot compared to #11430
as this is not meant to let CDN's or other parties in-between cache pages as it still sends
private, must-revalidatehttps://github.com/symfony/symfony/blob/6f4f04b98f6134996a57d21d1851d558a34dc45c/src/Symfony/Component/HttpFoundation/ResponseHeaderBag.php#L246
Instead this is meant to support revalidation instead of never being allowed to serve from browser cache.
They will function together without any problems though.