Two versions of Cache for the same url?

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
3 months ago

People

(Reporter: ziyunfei, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8754798 [details]
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

2 years ago
Can you put your test online?

Ehsan, does this ring any bells?
Flags: needinfo?(ehsan)
(Reporter)

Comment 2

2 years ago
Created attachment 8754806 [details]
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

2 years ago
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?
Flags: needinfo?(ehsan) → needinfo?(honzab.moz)
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.
Flags: needinfo?(honzab.moz)
And other question: is this bug about a problem in DOM cache or HTTP cache actually?  It's not clear.

Comment 6

2 years ago
(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.
Flags: needinfo?(honzab.moz)
> 4) In web console type fetch('https://tools.ietf.org/html/rfc103')

You meant rfc1034 ?
Flags: needinfo?(honzab.moz)

Comment 8

2 years ago
(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.
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)
(Reporter)

Comment 10

2 years ago
Created attachment 8754882 [details]
sudo node server.js

run `sudo node server.js` then open http://127.0.0.1 in Firefox.
will look next week, thanks.
Flags: needinfo?(honzab.moz)

Comment 12

2 years ago
(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.
(Reporter)

Comment 13

2 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID

Comment 14

2 years ago
Filed https://github.com/whatwg/fetch/issues/307 on Fetch.
Flags: needinfo?(honzab.moz)
You need to log in before you can comment on or make changes to this bug.