Chrome (59.0.3071.115): window.location.reload(true) reloads from cache, not server as it should...

[David Spicer]

Latest version of Chrome  for Mac (59.0.3071.115) javascript: window.location.reload(true) does NOT reload from server and just reloads from cache. Prior to updating Chrome, the last version of ’59’ I was using (don’t have the complete version number as I was not expecting this to break…) this worked as documented.  Need function to work as documented. Functionality should be the same as manual: hold down <control> click 'Refresh'

[PhistucK]

Can you update Chrome to Chrome 60 (it was just recently released) and see whether this still reproduces?

If it still reproduces, can you provide a URL that reproduces it?

☆PhistucK

On Wed, Jul 26, 2017 at 9:28 PM, David Spicer <harle...@gmail.com> wrote:

Latest version of Chrome  for Mac (59.0.3071.115) javascript: window.location.reload(true) does NOT reload from server and just reloads from cache. Prior to updating Chrome, the last version of ’59’ I was using (don’t have the complete version number as I was not expecting this to break…) this worked as documented.  Need function to work as documented. Functionality should be the same as manual: hold down <control> click 'Refresh'

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[David Spicer]

Does not work in Chrome 60 either. Can't send a link because one of the files needs to be changed to demonstrate the issue. Attaching a zip file that you can unzip in any directory with access from a webserver. Two Files: ReloadTest.html, and ReloadTest.js. Once installed on webserver, point chrome at ReloadTest.html and read instructions. Works correctly on every other browser I've tried, including Chrome ON IPHONE... Just not Chrome for desktop...

Apparently can't attach a zip containing a .js file. Any suggestions?

Thanks, Dave

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[David Spicer]

OK, here's a workaround. Renamed the .js file .jss to get passed the problem, Everything works a described in previous email.

Thx, Dave

Dave Spicer (770-335-4975) LinkedIn

[PhistucK]

I might try it tomorrow, but note that the server (and its configuration) is an important piece of the puzzle here. I would not be surprised if it did not reproduce for me.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[jlm]

The example works fine for me when deployed on a local nodejs server. The OP should provide data from Chrome Developer Tools Network Tab including the response headers from the 1st request of the js file and status code for the request of the js file after it is modified and the location.reload(true) is executed.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[David Spicer]

Jim: Does 'works fine' mean that you were able to replicate the problem?

[jlm]

I do not experience any problem at all.

You need to use Chrome Developer Tools Network tab to diagnose what is going on with your server.

[David Spicer]

Jim: Two screenshots using Chrome Developer Tools Network Tab as you suggested: TestControl-Refresh.jpg is after manually holding <Control> and clicking Refresh. Note that in the 'Size' column ReloadTest.jss and the jquery library have been reloaded from the server since they have non-zero values.

Now look at TestJavascritpReload-True.png. After executing location.reload(true), the 'Size' column shows that both ReloadTest.jss and jquery library are 'From Memory Cache' which means they were NOT retrieved from the server which is the incorrect behavior.

To run this test make sure that 'Disable Cache' is NOT checked in the Chrome Developer Tools Network Tab.

[jlm]

It would be helpful to see the headers for the original request.  When you go to dev tools, check Preserve Log. then do the manual refresh. click the ReloadTest.jss item to expand the headers and send that screenshot

I've attached two examples. In reload_test_jquery... you can see that it was served from the cdn with an expiration date of 12/31/2037 and a high max-age in cache-control, so it would have been served from cache.  See ReloadTest_js_... to see that on my system the ReloadTest.js is served without expiration and with max-age=0.  This will cause a subsequent request to use the ETag value which will get a 304 if the file has not been changed or a 200 with data from the server if the file has been changed

So I'm interested in seeing the response headers from the very first request for ReloadTest.jss

Hope this helps

[David Spicer]

Dave Spicer (770-335-4975) LinkedIn

---------- Forwarded message ----------
From: David Spicer <harle...@gmail.com>
Date: Mon, Jul 31, 2017 at 9:56 PM
Subject: Re: [chromium-discuss] Chrome (59.0.3071.115): window.location.reload(true) reloads from cache, not server as it should...
To: jlm <jlmsp...@gmail.com>

Jim: Here's the screenshot you requested. The spec as I understand it is that 'location.reload(true)' is to bypass the cache and retrieve files from the server, just as <control><Refresh> does manually. Chrome releases prior to '59' worked this way, and the current version of Chrome on iPhone works as well.

Dave

Dave Spicer (770-335-4975) LinkedIn

[David Spicer]

Dave Spicer (770-335-4975) LinkedIn

---------- Forwarded message ----------
From: John L Magee <jlmsp...@gmail.com>
Date: Tue, Aug 1, 2017 at 12:31 AM
Subject: Re: [chromium-discuss] Chrome (59.0.3071.115): window.location.reload(true) reloads from cache, not server as it should...

To: David Spicer <harle...@gmail.com>

Dave- The spec, https://html.spec.whatwg.org/multipage/history.html#dom-location-reload , is not specific and only references the "active document" without including referenced objects as I read it. So the html document is reloaded but both the jquery and the ReloadTest.jss are served from cache in the current Chrome.

Now it turns out that current Firefox 54.0 behaves as you expect. Chrome clearly does not. I'd consider this to be a big "So what" and I'm not trying to be a Chrome defender.

The issue almost certainly lies with the fact that the ReloadTest.jss file is being delivered without a cache-control (http/1.1) or pragma (http/1.0) or expires header. As such, cache management is left to the discretion of the User Agent (browser). And over the past 15+ years the behavior of different browsers has varied widely.

I gather your server is using tomcat6 or tomcat7 or some older version of JBOSS. All of these are notoriously problematic when delivering static content without some careful configuration.

I'm sure you will be able to achieve your desired result with the addition of headers to manage cache behavior.

On Mon, Jul 31, 2017 at 9:56 PM David Spicer <harle...@gmail.com> wrote:

Jim: Here's the screenshot you requested. The spec as I understand it is that 'location.reload(true)' is to bypass the cache and retrieve files from the server, just as <control><Refresh> does manually. Chrome releases prior to '59' worked this way, and the current version of Chrome on iPhone works as well.

Dave

Dave Spicer (770-335-4975) LinkedIn

On Mon, Jul 31, 2017 at 7:14 PM, jlm <jlmsp...@gmail.com> wrote:

[David Spicer]

John: (sorry, been calling you ‘jim’ …) Based on my testing, in Chrome, the ‘active’ (highest level document) ReloadTest.html document is ALWAYS reloaded from the server no matter how it has been refreshed.

As for the contained documents (.js files), the behavior of chrome for desktop was changed around release ’59.’  reload(true) used to force reload from server of all contained documents, and still does in other chrome variants (e.g., iPhone). Also, I cannot find another browser that does not. Understand that the new behavior provides an optimization of reload(true), but for ‘older’ servers, the default behavior when those cache headers are not provided should be to reload the file from the server. This would be consistent with: Chrome’s past behavior, behavior or every other browser, and consistent with the desired behavior of reload(true).

Are you an employee of Google? My first time using this forum…

Dave Spicer (770-335-4975) LinkedIn

On Tue, Aug 1, 2017 at 12:31 AM, John L Magee <jlmsp...@gmail.com> wrote:

Dave- The spec, https://html.spec.whatwg.org/multipage/history.html#dom-location-reload , is not specific and only references the "active document" without including referenced objects as I read it. So the html document is reloaded but both the jquery and the ReloadTest.jss are served from cache in the current Chrome.

Now it turns out that current Firefox 54.0 behaves as you expect. Chrome clearly does not. I'd consider this to be a big "So what" and I'm not trying to be a Chrome defender.

The issue almost certainly lies with the fact that the ReloadTest.jss file is being delivered without a cache-control (http/1.1) or pragma (http/1.0) or expires header. As such, cache management is left to the discretion of the User Agent (browser). And over the past 15+ years the behavior of different browsers has varied widely.

I gather your server is using tomcat6 or tomcat7 or some older version of JBOSS. All of these are notoriously problematic when delivering static content without some careful configuration.

I'm sure you will be able to achieve your desired result with the addition of headers to manage cache behavior.

On Mon, Jul 31, 2017 at 9:56 PM David Spicer <harle...@gmail.com> wrote:

Jim: Here's the screenshot you requested. The spec as I understand it is that 'location.reload(true)' is to bypass the cache and retrieve files from the server, just as <control><Refresh> does manually. Chrome releases prior to '59' worked this way, and the current version of Chrome on iPhone works as well.

Dave

Dave Spicer (770-335-4975) LinkedIn

On Mon, Jul 31, 2017 at 7:14 PM, jlm <jlmsp...@gmail.com> wrote:

[John L Magee]

David- I'm not a Google employee. I just have a couple of decades developing and supporting web based applications. I lurk on this group to watch for insights on new Chrome issues and occasionally try to help someone.

In spite of your sentiment regarding current Chrome behavior, I strongly suggest you configure your servers to implement appropriate cache-control  headers just to protect yourself from other unexpected peculiarities in the future. Although I'm not familiar with the details, I'm pretty sure it can be done with Tomcat output filters

[PhistucK]

I put the files on a GitHub Gist and used rawgit.com to serve them -

https://rawgit.com/phistuck/c6ae61673e3b456bce09c26459ddb12e/raw/675078ea4c0e10166d8b2292496370d614f9b984/ReloadTest.html

I tested using BrowserStack.

Chrome 58 - 60... - requests the main document from the server (but receives HTTP status code 304), loads the resources (JavaScript files) from the cache.

Chrome 57 - requests everything from the server (but receives HTTP status code 304).

So the change started in Chrome 58 (not Chrome 59 as you noted). Perhaps this blog post is related -

https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html

I am not sure this is the intended behavior (perhaps only the reload button should have been affected, perhaps not).

Takashi Toyoshima, can you advise?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[David Spicer]

John: 

Impressed by your depth of knowledge (which led me to think you might be a googler...) and appreciate your insights. It's not my servers I'm concerned about, they can be fixed with filters as you suggest. The test I put together was the minimum set of files I could use to isolate the issue. My production technology is IdentityJS (IdentityJS.com) and will be loading javascript files from servers over which I have no control. I'd like to see Chrome behave as it did prior to 58, as PhistucK mentions in his post below and as every other browser in existence does today. Does anyone from Google read these posts? I hesitate fixing my server as then I won't have a way to test if behavior has changed...

[PhistucK]

That rawgit.com link should stay stable for some time (if not a long time, but no guarantees), so you could always have a way to test the behavior.

Googlers indeed read these posts (less frequently, but they do) and I added the specific Googler that was part of the reload change effort to the thread in case that Googler missed it.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[David Spicer]

Thanks for jumping in (and including the Googler...). My concern with 'fixing' my server is then I won't have an 'old' server for testing. rawgit.com already provides the cache control headers. I need one that does not...

I maintain that the changed Chrome reload(true) policy is actually exhibiting age-discrimination!! Accessing an app on an 'old' server that has not updated to latest headers should produce the same results to match user expectations as servers that have the new(er) headers. No cache-headers => reload from server. If there is a 'penalty' it is going to be paid by the old server in the form of sending more information than absolutely required, eating cpu and disk-io. Ultimately the owner of the server will add the new headers to reduce overhead and save $$ but functionally, the end user on the browser should never see any difference.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[PhistucK]

But I thought your "old" server reproduces the same behavior (not the headers, but the end result) that rawgit.com exhibits, am I wrong?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[David Spicer]

Wrong. My 'old' server does NOT support the new headers and thus with Chrome, always returns the cached value of

ReloadTest.jss, which is how I discovered the problem when Chrome 58 came out (thanks for resolving in which release the change was made). I can't predict what servers will be used with IdentityJS and want to be aware of IF/WHEN google reverts to the proper functionality for reload(true).

Thanks for your help in resolving.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[jlm]

David- let me try one more time to help you. Use standards, not hope, to configure your servers to control how caching of documents is managed by browsers. I already provided reference to the location.reload() spec which is silent on the handling of documents referenced within the document being reloaded. The current specification for cache handling is https://tools.ietf.org/html/rfc7234. You should review this RFC concentrating especially on Section 4. 

Trying to define "proper" behavior by citing "past" behavior of a browser or comparing behavior to that of a different browser will not likely ensure consistent behavior of your applications for your users. You have, and should implement, the ability to control cache behavior.

This is not a matter of "old" servers and "new" headers. It is a matter of managing cache behavior for your users. It is your responsibility as the developer of a web site or web-based application. If you do not have any control of the servers delivering your documents, you should probably move your site/application.

Hope this helps put the topic in perspective.

[PhistucK]

Mmm... I am sorry, but your reply just further confused me.

Let me try to detail the whole situation...

1. The rawgit.com reproduction on Chrome 57 and earlier - loads JavaScript from the server.

2. Your "old" server on Chrome 57 and earlier - loads JavaScript from the server.

3. The rawgit.com reproduction on Chrome 58 and later - loads JavaScript from the cache.

4. Your "old" server on Chrome 58 and later - loads JavaScript from the cache.

Anything wrong in the four points above? If so, please, correct me.

5. Also, what are you trying to achieve with reload(true)?

6. What would you expect reload() to do?

7. What would you expect F5 to do (for which reason you do not use it)?

8. What would you expect Control + F5 (or Control or Shift + click on the reload button) to do?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[David Spicer]

jlm: Has nothing to do with my servers... Companies using my technology will be loading js from THEIR servers over which I have no control. After a user has the application running, if a change is made to one of the JS files, the system detects that and issues a reload(true). If the server (over which I have no control) supports the cache headers, the user's app will re-initialize from server. If the server is 'old' the app will not re-initialize since it is still using the cached js.

Dave Spicer (770-335-4975) LinkedIn

[David Spicer]

PhistucK: What your missing is that before each of the four tests you show, you must first set starting conditions:

• Force load from server (<control><refresh>) and note the value of the text in Green font
  
• Then, before another refresh, make a change to the green text in the ReloadTest.js file and save it.
  
• Then click on 'Click here' in the html to cause javascript to run: location.reload(true)
  

Then your tests 3 and 4 should ignore what is in the cached ReloadTest.js file and return the newly saved server version with the value of the changed text since it is newer than the cached version of ReloadTest.js.

then for questions 5-8:

5. Also, what are you trying to achieve with reload(true)?

             The same functionality as <control><refresh> and force reload of all files from server, the behavior in version 57

6. What would you expect reload() to do?

             The same functionality as <refresh> (without <control>) and refresh just the top level html file.

7. What would you expect F5 to do (for which reason you do not use it)?

             F5 on a Macbook controls keyboard illumination...

8. What would you expect Control + F5 (or Control or Shift + click on the reload button) to do?

            Force reload of all files from server

So when Chrome went from 57 to 58, the javascript function: location.reload(true) went from <control><refresh> to just <refresh> for servers that don't support cache-control headers.

Dave Spicer (770-335-4975) LinkedIn

[PhistucK]

(F5 on Windows reloads the page, probably equivalent to clicking on the reload button)

You did not really answer my first question, but, nevermind.

Changing the file would not matter at all, since the browser does not request it from the server anyway.

I would just assume that you do get the same behavior that rawgit.com shows, regardless of the headers.

☆PhistucK

[David Spicer]

Actually, the test does require that we modify ReloadTest.js since the whole point of the test is that we want to know how Chrome refresh works after the initial load of the page and then the js file is updated without Chrome knowing it. When the server supports cache headers, the browser sends the 'if-modified-since' timestamp of the last time it saw ReloadTest.js. When the server receives that request, it looks at the current timestamp and if they are not equal, returns the file with status 200.  If the timestamps match, the server returns a 304 status which tells the browser to use what is in the cache.

If timestamps match the 304 response transfers just about 350 bytes. If they do not match the 200 response transfers the entire file which is likely a lot more than 350 bytes.

Attaching two screenshots using a server that supports cache control: 'Reload Timestamps Match.png' and 'Reload Timestamps Do Not Match.png' very different behavior.

Since release 58, with a server that does not support cache control, Chrome just uses the cache. Prior to 58, it retrieved the file from the server. Needs to go back to the old behavior since if it does not know current status of ReloadTest.js it should retrieve it to be safe.

Dave Spicer (770-335-4975) LinkedIn

[John L Magee]

In 2017, no respectable web server would deliver documents without cache management headers.  Java-based servers that are not correctly configured have been deployed by amateurs or incompetents.  You are wasting your energy trying to get a browser to modify its behavior when that behavior meets the specification in RFC 7234.

[PhistucK]

I am not sure what you are trying to show with the screenshots, because both of them show the same cache response headers.

☆PhistucK

[PhistucK]

Oh, sorry, I got it now.

I am still waiting for a reply from Takashi Toyoshima.

☆PhistucK

[David Spicer]

PhistucK: appreciate your help. In reviewing the RFC, it is clear what  cache-control headers are supposed to do, but when it comes to the default behavior when the server does not understand those headers, the RFC is silent as far as I can see. Every browser I've tested, including Chrome for iPhone and Android appears to request the file when the server does not support cache-control. The only exception is Chrome >57 which now refreshes from the local cache. I'd like to see Chrome be consistent with all other browsers and its own <=57 behavior but understand this may be wishful thinking. IdentityJS provides built-in version management capabilities which is what triggers the location.reload(true) invocation when an existing session needs to be upgraded. When I have a customer complaining that it is not working on the server where his JS libraries reside and that server does not support cache-control, the standard response is going to be 'fix your server.'

Love to hear from the Googler on this one, but until then, going back to work. Appreciate the insights of everyone who has commented. This is a great forum.

Dave Spicer (770-335-4975) LinkedIn

[PhistucK]

I am not sure Chrome would not change. Even if it is compliant with the standards, the team does want Chrome to interoperate with other browsers so developers would write code once that just works everywhere.

Also, note that Chrome for iOS is not a good example for anything. Chrome for iOS is simply a skin of Safari. It does not use Blink or the network stack.

☆PhistucK

[Takashi Toyoshima]

Sorry, I just find this thread now.

Yes, that's my intentional change, and shipped at m59 (partially, or temporarily enabled even on m58).

discussion thread: https://groups.google.com/a/chromium.org/d/topic/loading-dev/gD-MPRcfwVA/discussion

Some notes:

 - standardized location.reload() does not take a boolean flag. It's Firefox specific.

 - there is no clear spec to explain how reload actually works, e.g. what kind of cache-control flags are used for each request, how each referrer should be modified, scroll restorations, form contents, etc, etc... this is kind of intentional, and decisions are deferred to browser implementation.

 - developers should manage cache-control headers correctly for productions rather than depending on reload behaviors. for testing, DevTools is your friends.

--

Takashi Toyoshima
Software Engineer, Google

[David Spicer]

What is your reference for the definition of location.reload() indicating  reload does not take a boolean flag??

Every definition I find agrees that location.reload(true) means 'forced reload' from server:

https://msdn.microsoft.com/en-us/library/ms536691(v=vs.85).aspx

https://developer.mozilla.org/en-US/docs/Web/API/Location/reload

https://www.w3schools.com/jsref/met_loc_reload.asp

http://man.hubwiz.com/docset/JavaScript.docset/Contents/Resources/Documents/developer.mozilla.org/en-US/docs/Web/API/Location/reload.html

Every other browser I've tested interprets this as forced reload, and so did Chrome at <=57. Why purposely change it to be incompatible??

Dave Spicer (770-335-4975) LinkedIn

[PhistucK]

Those are not definitions, those are references that describe some specific implementations.

The HTML Living Standard -

https://html.spec.whatwg.org/multipage/history.html#dom-location-reload

And the HTML5 W3C Recommendation -

https://www.w3.org/TR/html5/browsers.html#dom-location-reload

Do not describe location.reload() as taking a parameter.

While every implementation (until Chrome 57) implemented that parameter, nothing official described the standard behavior of that parameter. While you found a case where it only now (well, Chrome 58+) differs, every implementation probably has edge cases or differences that you may or may not be aware of, because it is not a standardized behavior.

☆PhistucK

[Dan Spacy]

I don't quite get it, wasn't the idea of the discussion in https://groups.google.com/a/chromium.org/forum/#!topic/loading-dev/gD-MPRcfwVA/discussion that you should stick to two types of reloads: One that use the cache and one that don't? So that F5 reloads like location.reload() and that Ctrl-F5 reloads like location.reload(true)? Because the behavior I see now is that Ctrl-F5 disregards the cache, while reload(true) does not.

My specific use case taking me here is an authenticated rich web application where I have to handle expired sessions. I thought I could use location.reload(true) to force a reload that would redirect to the login page, but since it does not work in chrome I have to implement some other hack to force the browser to actually reload the resource. I can't even redirect to the login page myself since it's a general SSO-solution in front of the servers that provides an authentication form on unauthenticated requests. Hack works, but I think it's sad that I can not rely on simply location.reload(true).

 location.reload(bool) might not be officially defined, but it seems to be quite well defined de facto, except from your recent change.

☆PhistucK

Dave Spicer (770-335-4975) LinkedIn

☆PhistucK

☆PhistucK

Dave Spicer (770-335-4975) LinkedIn

☆PhistucK

Dave Spicer (770-335-4975) LinkedIn

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

<b

[1jeffchr...@gmail.com]

David Spicer,

I love how you handled this conversation. I have the exact same need that you have. And I see it exactly as you do. I applaud you for your patience in working to help others understand the issue.

Chromium team, I agree with David Spicer and Dan Spacey that reload(true) is a well defined de facto that you have now broken for many of us.

Jeff

[John L Magee]

You can be as stubborn as you want on this topic but until you fix your cache control headers, you will not provide your users with the desired experience.  It may vary by browser but since about 80% of modern browsers are now Chromium-based, this is what they'll get. 

You received this message because you are subscribed to a topic in the Google Groups "Chromium-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-discuss/T3uNqzSiM0Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-discu...@chromium.org.