Tested this issue on Mac OS 10.11.6 using chrome latest dev M54-54.0.2824.0 by following steps mentioned below.

1. Opened chrome window and navigated to inspect element
2. Disabled cache from the network panel
3. Loaded the provided URL 
4. Observed 2 Get script in console tab

bzbarsky@- Attaching screen-cast from our end, Could you please confirm is this is the expected behavior of this issue? If yes, please recheck this issue by creating a new profile under chrome://settings with out any apps or extensions in your browser.

Thanks!

Deleted: 640069.mp4 801 KB

	640069.mp4 801 KB View Download

Your video shows one GET for the page itself and one GET for the script.  There should be one GET for the page and two GETs for the script, for three loads total.  So your video is showing the incorrect behavior happening.

Charles, does this ring any bells for you?  I have some vague memory you've looked at issues like this before.

@bzbarsky: Can you try to reproduce with a new profile as per c# 1?

Not a network issue, this is all Blink cache.

+japhet,hiroshige for help here, as I'm not familiar with the spec side of things. 

This happens with a new profile, yes.  It also happens in the video attached with c# 1...

I don't have access to a Mac to test right now, but it would be useful to know if Safari also has this problem.

It does, yes.

The script is preloaded. Blink uses a preloaded resource stored in the memory cache even if the "Disable cache" option is specified.

But should we match two script tags to the same script resource in memory cache? bzbarsky is claiming the spec does not allow this.

I think this is orthogonal to whether or not the scripts are preloaded. The second one just matches the first one in memory cache.

The current code merges multiple preload requests.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?q=determineRevalidat&sq=package:chromium&l=657

Because there are two identical script tags, I think the more relevant snippet is this one:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?rcl=0&l=752

// During the initial load, avoid loading the same resource multiple times for a single document,
// even if the cache policies would tell us to.

This is the logic that coalesces
<script src=X></script>
<script src=X></script>
into one fetch even if neither script initiated a preload.

Yeah, that's true. Even if the server doesn't allow us to reuse the resource, Blink reuses it.

I don't think this should be marked available until we know the behavior should change here. We've established that this is currently working as intended for Blink architecture, but should we change Blink architecture to satisfy the spec?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Loading triage:

According to the spec, at the step 4 of the fetch a classic script algorithms, it does 'perform the fetch'.

https://html.spec.whatwg.org/multipage/webappapis.html#fetching-scripts-perform-fetch

> The algorithms below can be customized by optionally supplying a custom perform the fetch hook,

and

> The hook can also be used to perform more subtle customizations, such as keeping a cache of responses and avoiding performing a fetch at all.

So, the originally reported scenario sounds no-problem in terms of the spec.

The problem here would be

 - multiple requests in the same document are shown as a single request in DevTools
 - server's intention to disallow caching does not affect disk/memory cache since we decide to reuse the same Resource before getting the response header.
 - 'disable cache' does not actually disable the memory cache, but just flush out cached entries on starting page load, though disk cache is disabled as we expect.

These may be a little confusing for DevTools users, but have no real issues

I think these are by design at this point, and wouldn't have a plan unless we found a real problem.

Based on analysis at c#17, I'm marking this WONTFIX