window.document.reload() and validation




2 years ago
13 days ago


(Reporter: karlcow, Unassigned)


48 Branch

Firefox Tracking Flags

(Not tracked)




2 years ago
In the comment 12 about chromium bug on implementing `Cache-Control: immutable`

> 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
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
Change behavior of Reload to (validate main resource + regular load) instead of the current forced reload which triggers conditional requests on all the things


2 years ago
Summary: window.document.reload() → window.document.reload() and validation


2 years 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)

Comment 3

2 years 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)
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

2 years 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, 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"?
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.