Bug 80439 – Race condition in handling non-cachable resources.

• Status: NEW
• Component: Page Loading

[Brian Kuhn]

Originally filed as a Chrome bug:
http://code.google.com/p/chromium/issues/detail?id=116988


Chrome Version       : 18.0.1025.39
OS Version: 
URLs (if applicable) : http://examples.nfshost.com/nocacherace/result1/index.html http://examples.nfshost.com/nocacherace/result2/index.html


Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
    Firefox 9: OK
         IE 9: OK

What steps will reproduce the problem?
Visit a page that loads a non-cachable script and an iframe that also uses that script.  The unexpected behavior happens if the iframe loads before the script finishes loading.

What is the expected result?
The main page and the iframe should get different copies of the non-cachable script, which is exactly what happens in all other cases.

What happens instead?
The script in the iframe is not requested; instead the copy from the main page is used. If this were to always happen, fine. But it only happens if the iframe is parsed while the script on the main page is mid-download. It seems like Chrome is assuming that the mid-download resource is cachable.


Please provide any additional information below. Attach a screenshot if
possible.

Please see the test cases I've developed to demonstrate the problem:
http://examples.nfshost.com/nocacherace/result1/index.html
http://examples.nfshost.com/nocacherace/result2/index.html


UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.39 Safari/535.19

[Alexey Proskuryakov]

This is a long standing problem in the loader, but I'm not sure if we have a bug clearly covering it already.

[Brian Kuhn]

Is there no interest in fixing this?

[Nate Chapin]

At a 2 minute glance, my guess is that the if statement at http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.cpp?rev=128914#L583 is too broad. It should probably check the Frame that initiated the CachedResource load, the response headers, or both.

[Brady Eidson]

(In reply to comment #2)
> Is there no interest in fixing this?

Do you have a case for why this needs to be higher priority work than what folks are already working on?

You're also welcome to tackle it yourself!