Skip to content
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

Grav serving stalled content: Last-Modified ignore modular pages last modification date #3561

Open
drzraf opened this issue Mar 17, 2022 · 1 comment · May be fixed by #3562
Open

Grav serving stalled content: Last-Modified ignore modular pages last modification date #3561

drzraf opened this issue Mar 17, 2022 · 1 comment · May be fixed by #3562

Comments

@drzraf
Copy link
Contributor

drzraf commented Mar 17, 2022

In #2168 someone requested that the template modification be taken into account when computing the Last-Modified header.
It happens that the time computed from this header is based exclusively on the main page last modification time even if has multiple (more recent) children modular pages.

The consequence is that when someone reaches such a Grav page their browser first check Cache-Control: max-age (see #3560) and, if the content is deemed expired, the browser will send a If-Modified-Since header (using the Last-Modified) date.

If any caching-proxy exist between the user and Grav, it's likely to send a 304 Not Modified (because of the wrong Last-Modified date) leading the stale content being served to the users.

The consequence depends on the browsers but I've got reports pointing this pervasive behavior affecting many users (including our own editors).
Some browser vendors may simply not send the If-Modified-Since is loading the URL from the address-bar or from a the Back button, or from a hard-refresh or if the debugger is opened. But most browser regularly visiting production-grade Grav instances are suffering this issue.

@rhukster
Copy link
Member

I hear what you are saying, and i've certainly seen this scenario, but the problem is how to know what other pages (modular, or even just content from another regular page) and if modifications of these impact the main page. Checking a modified date of every page included in a collection could be time consuming and there is no guarantee that these pages are used in the actual output of the page, they might be for something else entirely.

What i'm saying is I agree it would be great to have this functionality, but i'm not how we could achieve it. Especially when you take into account that most of this logic happens at the Twig level which makes it very hard to intercept and do a calculation like this.

I'll discuss it with @mahagr and see if there's any way to achieve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants