Steps to reproduce
Microsoft Edge is reusing the cached version of main.js without sending a request to the server to check for a newer version even though the file is served with a Date and an Etag header.
This could affect production users when that file changes, but iis particularly problematic when trying to use webpack or webpack HMR during development as even though the etag changes and Chrome/Firefox/IE 11 successfully get the new version on subsequent visits Edge uses the version from its local cache.
Microsoft Edge 40.15063.674.0
Microsoft EdgeHTML 15.15063
Response Header from initial request for main.js during a request to localhost:8080 which then has a script main.js after clearing cache looks like
Date:Tue, 07 Nov 2017 00:12:13 GMT
Upon subsequent visits to localhost:8080 localhost is sent a request and the server responds with a 304 because the index.html has not change. However Edge then proceeds to use main.js from local cache even though main.js has changed and if Edge requested it using the etag it would get a 200, not a 304.
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Steven K.”
Also, can you send either a network trace from the F12 debugger and/or a URL you are using to test this? I want to check the control-control and pagrma header’s as well.
I am uploading 2 .har attachments from Edge and 2 from Chrome.
The problematic case is the one named “localost new visit after change-Edge.har” In this trace the main.js file has changed, but Edge uses the cached version.
The localhost-hmrCange-localhost-Edge.har file shows my initial visit to the page today along with an hmr hot update (which results in the change to main.js).
I am not an expert on the caching RFCs, but II suspect what Edge is doing might be technically valid, but different from behavior of other browsers which do a different technically valid thing.
In the absence of a cache-control: no-cache header I don’t think its required for Edge to send a cache validation request, nor is it specified that it shouldn’t. Matching the behavior of other browsers in this case would enhance compatibility/interoperability.
Adding a Cache-Control: no-cache header results in the desired behavior/the behavior of other browsers in the absence of the header.
I was just going to ask if you could redo the test using Fiddler. I do not see the request header for main.js in the Edge har file. Are you saying Edge is not sending any E-tags?
That appears to be the behavior. Edge doesn’t send any request/e-tags to the server for main.js in this scenario. It just uses the cached version without verifying it is still valid/current.
I just realized my first comment was not labelled to get sent/published. The message exchange was probably a bit confusing. Not sure posting this now will help but wanted to let you know.
Would you be willing to provide a simple repro for this and attach it to this bug report?
Appreciate the submission and support,
I appreciate the update and the extra testing. I will forward the information about the difference in the default cases.
- Microsoft Edge Team
Changed Assigned To to “Venkat K.”
Changed Assigned To to “firstname.lastname@example.org”
Changed Assigned To from “email@example.com” to “Sirajudeen S.”
Changed Status to “Confirmed”
Changed Assigned To from “Sirajudeen S.” to “Brandon M.”
Changed Status from “Confirmed” to “External”
This issue has been resolved External. This means this issue may require a new feature to be implemented or other work that is more significant than a typical bug. You may be able to find more information on this issue by searching for related features on status.microsoftedge.com and uservoice.microsoftedge.com.