1274555 - Two versions of Cache for the same url?

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[ziyunfei]

Attachment: Two versions of Cache.mp4

https://127.0.0.1 is an html page which returns a different number each time it's accessed, like this:

$ curl https://127.0.0.1
1
$ curl https://127.0.0.1
2
$ curl https://127.0.0.1
3
...

See attached screencast, normal page requests and Fetch API use two different caches for the same url.

Comment 1

[Anne (:annevk)]

Can you put your test online?

Ehsan, does this ring any bells?

Comment 2

[ziyunfei]

Attachment: Screen Shot 2016-05-20 at 8.49.48 PM.png

(In reply to Anne (:annevk) from comment #1)
> Can you put your test online?
>

This is not a special case, you can repro in any pages.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I only see this for top level loads.  Subresources like stylesheets use the same cache entry.

Here's another site I tried:

https://tools.ietf.org/html/rfc1034

I see a single entry in about:cache before and after the fetch().

Honza, do you know why we would get a cache miss for a URL matching a loaded document?

Comment 4

[Honza Bambas (:mayhemer)]

What exactly the "cached" under "Transferred" means?  And why do you think there are two cache entries for the same URL?  I don't see any indication there would be.  Please make the test case life.  Thanks.

Comment 5

[Honza Bambas (:mayhemer)]

And other question: is this bug about a problem in DOM cache or HTTP cache actually?  It's not clear.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Honza Bambas (:mayhemer) from comment #4)
> What exactly the "cached" under "Transferred" means?  And why do you think
> there are two cache entries for the same URL?  I don't see any indication
> there would be.  Please make the test case life.  Thanks.

Steps for a live example:

0) Open network panel
1) Open https://tools.ietf.org/html/rfc1034
2) Refresh
3) Observe in network panel that the navigation response is retrieved from http cache
4) In web console type fetch('https://tools.ietf.org/html/rfc103')
5) Observe in network panel that the fetch response appears not to be retrieved from http cache
6) Run fetch('https://tools.ietf.org/html/rfc103') again
7) Observe in network panel that the fetch response appears to be retrieved from http cache

(In reply to Honza Bambas (:mayhemer) from comment #5)
> And other question: is this bug about a problem in DOM cache or HTTP cache
> actually?  It's not clear.

Its about http cache.  Its filed in DOM because fetch() is being used.

Comment 7

[Honza Bambas (:mayhemer)]

> 4) In web console type fetch('https://tools.ietf.org/html/rfc103')

You meant rfc1034 ?

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Honza Bambas (:mayhemer) from comment #7)
> > 4) In web console type fetch('https://tools.ietf.org/html/rfc103')
> 
> You meant rfc1034 ?

Yes.  Sorry for the typo.

Comment 9

[Honza Bambas (:mayhemer)]

The ETag is constantly changing for https://tools.ietf.org/html/rfc1034.  It fluctuates between weak and strong.  Request made as 
   If-None-Match: "3c9ee2-26271-52f4c1d328bd6;53347d5d4de85" gets back 200 and 
   ETag: "3c9ee2-26271-52f4c1d328bd6;53347d6a4e1d9".

Definitely WFM, we behave correctly.  Please make the original localhost test case public or state more clearly what is the issue here.

Note that it's impossible to have two entries for the same URL in the same load context info (same originattributes/anonymous flag/private load tuple)

Comment 10

[ziyunfei]

Attachment: sudo node server.js

run `sudo node server.js` then open http://127.0.0.1 in Firefox.

Comment 11

[Honza Bambas (:mayhemer)]

will look next week, thanks.

Comment 12

[Anne (:annevk)]

(In reply to Honza Bambas (:mayhemer) from comment #9)
> Note that it's impossible to have two entries for the same URL in the same
> load context info (same originattributes/anonymous flag/private load tuple)

I think this might be the problem.

ziyunfei, can you reproduce with fetch(url, { credentials:"include" })? By default navigation and fetch() don't use the same credentials mode so the HTTP cache shouldn't be shared either. Fetch should probably spell that out since there's security implications if an implementation does not do that.

Comment 13

[ziyunfei]

(In reply to Anne (:annevk) from comment #12)
> (In reply to Honza Bambas (:mayhemer) from comment #9)
> > Note that it's impossible to have two entries for the same URL in the same
> > load context info (same originattributes/anonymous flag/private load tuple)
> 
> I think this might be the problem.
> 
> ziyunfei, can you reproduce with fetch(url, { credentials:"include" })? By
> default navigation and fetch() don't use the same credentials mode so the
> HTTP cache shouldn't be shared either. Fetch should probably spell that out
> since there's security implications if an implementation does not do that.

Anne, you are right. I overlooked that point. Thanks.

Comment 14

[Anne (:annevk)]

Filed https://github.com/whatwg/fetch/issues/307 on Fetch.