1111581 - [e10s] nsPrefetchNode fails with NS_NOINTERFACE (0x80004002), font prefetch fails

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[David Jones]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141127111021

Steps to reproduce:

I added a LINK element to the home page of a website to prefetch a web font so that it's quickly displayed on subsequent pages. (The font isn't used on the home page, only prefetched.) I set the LINK element's REL attribute to "prefetch" and I set the HREF attribute to the web font's URL (e.g., "http://localhost:3000/font.woff" when testing locally and "https://cdn.example.com/font.woff" on my employer's server).


Actual results:

When I test font prefetching locally, it works as expected in Firefox and Chrome. Both browsers' dev tools show that the font is downloaded on the home page and not downloaded on subsequent pages. Similarly, when I visit one of the non-home pages first and then visit the home page, the font is downloaded on the non-home page and not downloaded on the home page.

When I test font prefetching on my employer's server, it works as expected in Chrome, but not in Firefox. Firefox's dev tools show that the font is downloaded on the home page, but surprisingly, the dev tools show that the font is downloaded again on the next page. The font is not downloaded on other pages, only on the home page and the first page that's visited after the home page. When I visit one of the non-home pages first and then visit the home page, the font is downloaded on the non-home page and also downloaded on the home page, but it's not downloaded on any subsequent pages.


Expected results:

I expected that Firefox wouldn't download a font from a CDN twice.

Comment 1

[David Jones]

Additional details:

Only the font is downloaded twice

Comment 2

[David Jones]

Additional details:

Only the font is downloaded twice, not any of the other prefetched files, which include images, stylesheets, and JavaScript files.

Setting the LINK elements's TYPE attribute to "application/font-woff" had no effect.

Below is the result of running "curl -I https://cdn.example.com/font.woff".

HTTP/1.1 200 OK 
Date: Mon, 15 Dec 2014 14:15:04 GMT
Content-Type: application/font-woff
Content-Length: 65452
Connection: keep-alive
Strict-Transport-Security: max-age=31536000
Last-Modified: Mon, 15 Dec 2014 14:02:11 GMT
Cache-Control: public, s-maxage=31557600, max-age=31557600
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: x-requested-with
Access-Control-Max-Age: 3628800
Via: 1.1 vegur
Server: NetDNA-cache/2.2
X-Cache: HIT

Comment 3

[:Gijs (he/him)]

Is the CDN google? This looks like it's related to / a duplicate of bug 1060767.

Comment 4

[David Jones]

Hi, Gijs. The CDN that we use is MaxCDN. I've created a test site <http://111158.nfshost.com/> to demonstrate the issue. In addition to being the CDN that we use, MaxCDN also provides the public CDN for Font Awesome, so to keep things simple, I used MaxCDN's Font Awesome CDN for the demonstration.

Comment 5

[:Gijs (he/him)]

Thanks for the testcase!

I can reproduce this on Windows, and I agree it doesn't seem to make a lot of sense. After the 'real' (not prefetch) request of the font, it seems like subsequent refreshes of the page just get a 304, which makes more sense - but it's not clear to me why the prefetch doesn't just do that anyway. Jonathan, can you enlighten us as to what is going on here and if there's a font or http issue, or something else?

Comment 6

[Jonathan Kew [:jfkthame]]

Sorry, I don't know much about network requests, etc.

AFAICS, the "real" GET request for the font when visiting the "Display font" page does not (on the first load) include any of the headers such as If-Modified-Since that would make it a conditional GET, so the server has no choice but to return a full copy of the font. Which seems to suggest that the "prefetch" link has not recorded the prefetched resource in such a way that the subsequent "real" font request recognizes it as being the same. Maybe because the Accept header is different? But that's just me guessing wildly.... I think you need someone who actually knows a bit about the HTTP cache, requests, prefetch links, and all that.

Comment 7

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> I think you need someone who actually knows a bit about the HTTP
> cache, requests, prefetch links, and all that.

Fair! Trying McManus next. :-)

Comment 8

[Patrick McManus [:mcmanus]]

honza is the cache guru

Comment 9

[Honza Bambas (:mayhemer)]

I think the prefetch is using an anonymous load (XHR) but the "real" load is non-anonymous (a.k.a. "normal").  Each uses a distinct storage.

If confirmed, please close as INVALID.

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to Honza Bambas (:mayhemer) from comment #9)
> I think the prefetch is using an anonymous load (XHR) but the "real" load is
> non-anonymous (a.k.a. "normal").  Each uses a distinct storage.
> 
> If confirmed, please close as INVALID.

Does that mean this is not a supported use of prefetching? Is it documented somewhere which kinds of resources can usefully be prefetched, as specifying a prefetch link for a resource (and using bandwidth to download it) when it is not able to satisfy the "real" request is rather sad...

Should we be using an anonymous load in the userfont-loading code? (Is that what other resources do, given that they apparently work -- comment 2?)

Comment 11

[Honza Bambas (:mayhemer)]

I don't know what you are doing exactly, so it's hard to answer.  This bug just sounds like the prefetch is anonymous.

Please provide a simple proof of concept (a simple test case) so that I can reproduce to move forward here.

Thanks.

Comment 12

[:Gijs (he/him)]

(In reply to Honza Bambas (:mayhemer) from comment #11)
> I don't know what you are doing exactly, so it's hard to answer.  This bug
> just sounds like the prefetch is anonymous.
> 
> Please provide a simple proof of concept (a simple test case) so that I can
> reproduce to move forward here.
> 
> Thanks.

There's a link in comment #4 with a simple testcase.

Comment 13

[Jonathan Kew [:jfkthame]]

See above for details including testcase (comment 4).
To reproduce, with the Network tab open to observe requests (and assuming you start with an empty cache):
* Load http://111158.nfshost.com/
* Click the "Prefetch assets" link. Note that it fetches the HTML page, a CSS file, and a font.
* Go back
* Click the "Display font" link. Note that it re-fetches the font that was just prefetched.

Comment 14

[Honza Bambas (:mayhemer)]

>	xul.dll!nsPrefetchNode::OnStartRequest(0x04e9b450, 0x00000000) Line 251	C++
 	xul.dll!mozilla::net::HttpChannelChild::DoOnStartRequest(0x04e9b450, 0x00000000) Line 360	C++
 	xul.dll!mozilla::net::HttpChannelChild::OnStartRequest(NS_OK, {...}, true, {...}, false, true, 0x5692ad2b, {...}, {...}, {...}, {...}) Line 352	C++
 	xul.dll!mozilla::net::HttpChannelChild::RecvOnStartRequest(NS_OK, {...}, true, {...}, false, true, 0x5692ad2b, {...}, {...}, {...}, {...}, 0x0000) Line 296	C++


NS_IMETHODIMP
nsPrefetchNode::OnStartRequest(nsIRequest *aRequest,
                               nsISupports *aContext)
{
    nsresult rv;

    nsCOMPtr<nsICachingChannel> cachingChannel =
        do_QueryInterface(aRequest, &rv);
    if (NS_FAILED(rv)) return rv;


aRequest = [mozilla::net::HttpChannelChild]
rv = NS_NOINTERFACE (0x80004002)



nsPrefetchNode must go after nsICacheInfoChannel.  It's single/multiprocess compatible.

Jason, can you do it?  Feel free to bounce back.

Comment 15

[Dragana Damjanovic [:dragana]]

David, can you put the test that you have made back on, so i can test the patch?
Just to check, have you been using e10s?

Comment 16

[David Jones]

Dragana wrote:
> David, can you put the test that you have made back on, so i can test the patch?

Hi, Dragana. I needed to move the test to here: http://www.storylink.com/1111581/

> have you been using e10s?

No, I haven't. I enabled e10s in Firefox Developer Edition 37.0a2 just now, and it didn't seem to make a difference.

Comment 17

[Dragana Damjanovic [:dragana]]

Attachment: bug_1111581_v1.patch

Comment 18

[Dragana Damjanovic [:dragana]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=94e0bfac59e4

Comment 19

[Honza Bambas (:mayhemer)]

Comment on attachment 8569124 [details] [diff] [review]
bug_1111581_v1.patch

Review of attachment 8569124 [details] [diff] [review]:
-----------------------------------------------------------------

thanks!

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/af0e56fc81b3

Comment 21

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/138f4bb6fbde

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Re-landed, sorry for the churn.
https://hg.mozilla.org/integration/mozilla-inbound/rev/27f56cce6182

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/27f56cce6182