window.document.reload() and validation

NEW
Unassigned

Status

()

Core
DOM
P3
normal
5 months ago
2 months ago

People

(Reporter: karlcow, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 months ago
In the comment 12 about chromium bug on implementing `Cache-Control: immutable`
https://bugs.chromium.org/p/chromium/issues/detail?id=611416#c12

> Chrome no longer forces validation on reload, so immutable shouldn't be necessary.

and comment 13 says
> To add to #12, we might consider implementing Immutable if the following conditions are met:
> 1. there are substantial remaining opportunities
> 2. and they can only be addressed by adding this new API.


Linking to https://bugs.chromium.org/p/chromium/issues/detail?id=612701
This bug will track following changes.
 - Add some content browser tests for monitoring cache-control flags on each reload operations
 - Make the new reload (RELOAD_MAIN_RESOURCE) work nicely with DevTools. Currently, memory cache change the policy in a wrong way when DevTools is open.
 - Add new field study for desktop


with also
https://bugs.chromium.org/p/chromium/issues/detail?id=600636
Change behavior of Reload to (validate main resource + regular load) instead of the current forced reload which triggers conditional requests on all the things
(Reporter)

Updated

5 months ago
Summary: window.document.reload() → window.document.reload() and validation
(Reporter)

Updated

5 months ago
See Also: → bug 1267474
Is this bug proposing to change something or is it only to track a difference in reload behavior between browsers?
NI Karl for the question comment 1.
Flags: needinfo?(kdubost)
(Reporter)

Comment 3

5 months ago
It's a kind of heads-up. I'm not sure yet if we will get any differences of behaviors or incompatibilities for this. Google seems to tie this to their own future implementation of `Cache-Control: Immutable`. They don't seem to be decided yet.

This is not a proposal (yet) to change anything.

Thanks for asking Ben, sorry to not have been clearer in the initial description.
Flags: needinfo?(kdubost)

Updated

5 months ago
Priority: -- → P3
I guess my impression was chrome wanted to tie the "no revalidation" behavior to a max-age threshold.  If the max-age is above that value then the resource does not get revalidation on reload.

For what its worth I think we should try to avoid adding these kind of magic thresholds.  I think exposing "cache-control:immutable" as an explicit signal is much better.

Comment 5

4 months ago
(In reply to Ben Kelly [:bkelly] from comment #4)
> I think exposing "cache-control:immutable" as an explicit signal is much better.

I have been waiting for months for a bug reported in chromium's bug list by anyone else which may says "this Chrome's new reload behavior is not backward compatible!" since I reported https://bugs.chromium.org/p/chromium/issues/detail?id=654378#c2, but it turned out nobody noticed this change except me.

So maybe this aggressive change is backward compatible and we don't need "cache-control:immutable"?
You need to log in before you can comment on or make changes to this bug.