1049315 - Enabling HTTP2Draft prevents loading assets from s.ytimg.com, breaking youtube

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[mitchell]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140805030300

Steps to reproduce:

1. Run Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140805030300 CSet: 7f81be7db528, which has network.http.spdy.enabled.http2draft enabled by default.
2. Go to youtube.com



Actual results:

3. Enjoy a CSS-Free experience.

Inside the Network monitor Dev tool, the requests for CSS are listed, but have no response - no errors either. Edit and resend changes nothing. Copy the request as curl, run it in the terminal and it works fine.


Expected results:

4. Disable network.http.spdy.enabled.http2draft.
5. Suffer a CSS-burdened experience.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

WFM with a 32 bit build, perhaps http2 is not ready to play with 64 bit just yet ?

Comment 2

[Daniel Stenberg [:bagder]]

But... this is a http2 draft-14 build, right? And youtube doesn't speak h2 at all so it picks SPDY/3.1 (for me). I can't seem to repeat this problem on linux 64bit.

Comment 3

[alreiten]

WFM with 64 bit Fx on 64 bit Windows 7; using the Network tool, all s.ytimg.com CSS loaded.  Note: I am on Aug 6 build.

Comment 4

[Patrick McManus [:mcmanus]]

my 32bit build is still on aug 5.. will try again (either 64 bit or updated 32) when I get back online in an hour.

alreiten about:buildconfig would be useful - then we can be sure what bits you are running.

Comment 5

[Patrick McManus [:mcmanus]]

specifc url of a css that won't load would be good too. thanks

Comment 6

[Patrick McManus [:mcmanus]]

a 64 bit linux nightly with h2-14 defaulted on -

and https://s.ytimg.com/ yields a negotiation of spdy/3.1 - which is what I would expect today. Its an error page because I don't have the url of the css in question - but it likes like wfm on this config at least.

I'll try win64.

Comment 7

[Patrick McManus [:mcmanus]]

win64  https://s.ytimg.com/ is also wfm (negotiates spdy/3.1 as expected today).

If this persists for you, please generate an http log and let us know the particular URI in question:

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

hopefully that will shine some light on the issue.

Comment 8

[u408661]

Just one more data point: WFM on 64-bit OS X.

Comment 9

[Patrick McManus [:mcmanus]]

its possible reporter has a different endpoint (i.e. IP) with an interop problem.. log would show.

Comment 10

[mitchell]

Hi all, sorry for the delay. I am unable to repro this today. However, I was seeing some requests succeed to s.ytimg.com using HTTP/2 (as reported in the network panel). After restarting nightly to enable HTTP logging, this has not recurred. I'm througherly confused - perhaps google fixed the servers overnight?

Restarting nightly for http logging also updated it - did anything land which could change this? New build ID: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140806030201 CSet: 6cbdd4d523a7

Was unable to get HTTP logging working, anyway. Ran this in the cmd ling: http://pastie.org/private/38t4o0wxwqonyvaguhdw, no log made. Probably not needed, due to inability to reproduce anything now.

mcmanus: AFAIK all yt css loads from s.ytimg.com, so going to youtube.com makes it very obvious whether this is working or not. Here's a sample url anyway: https://s.ytimg.com/yts/cssbin/www-guide-vflA6E9AI.css

Comment 11

[Patrick McManus [:mcmanus]]

(In reply to mitchell from comment #10)
> Hi all, sorry for the delay. I am unable to repro this today. However, I was
> seeing some requests succeed to s.ytimg.com using HTTP/2 (as reported in the
> network panel). After restarting nightly to enable HTTP logging, this has
> not recurred. I'm througherly confused - perhaps google fixed the servers
> overnight?
> 

a google fix is one possibility.. another is that DNS is just pushing you at a different server today and that broken server is lurking out there.

> Restarting nightly for http logging also updated it 

there were no http2 updates made after the one that turned it on. but a restart will flush your connection cache, so perhaps that's just what you needed to see the server side change.

> 
> Was unable to get HTTP logging working, anyway. Ran this in the cmd ling:
> http://pastie.org/private/38t4o0wxwqonyvaguhdw, no log made. Probably not
> needed, due to inability to reproduce anything now.

weird. The way that has happened to me is that if firefox was still running (perhaps hidden) at the time.. the firefox.exe command will give you a new window on the old process so it can be confusing. Other than that, its always been fine for me.

> 
> mcmanus: AFAIK all yt css loads from s.ytimg.com, so going to youtube.com
> makes it very obvious whether this is working or not. Here's a sample url
> anyway: https://s.ytimg.com/yts/cssbin/www-guide-vflA6E9AI.css

thanks for that.

I'm going to close this WFM. Reopen if you re-encounter (and try the log again - or at the very least maybe try and figure out an IP address when it is happening via wireshark)