Error code -2?

WebPageTest Private Instances
1

I have run a test on my site with the following config:

Ubuntu 10.04 LTS
Nginx 1.0.11 (port 8080)
PHP5-FPM 5.3.2
Varnish 1.1 (port 80)
APC

I’m wondering what the hell #4 here is:

http://www.webpagetest.org/result/120207_1R_351E7/2/details/cached/#request4

and item #24 here (same thing):

http://www.webpagetest.org/result/120207_1R_351E7/2/performance_optimization/#cache_static_content

Seem’s it is google’s and it is served over HTTPS but it isn’t GA as that is loaded elsewhere in the list.

Any ideas?

Thanks!
Myles

2

Yeah, I need to figure out where in the code that default is set. The requests are probably SPDY over SSL which is something that the Chrome agent can’t decode yet. They aren’t errors, I just don’t have visibility into the actual requests (it’s something we are working on).

3

I didn’t think they had put SPDY into production yet, strange that they have pioneered the protocol and not built it into Chrome…

4

SPDY has been in production for well over a year. Most HTTPS requests to Google from Chrome uses SPDY. Chrome has had support for it for quite a while as well. What “I” don’t have yet is code in WebPagetest to decode SPDY streams and deconstruct the individual requests.

5

Ahh, understood apologies I misread. Thanks for the input Patrick!

Myles

6

I noticed this for my Website and spent hours going through the code for my site to check if there was an errant JS library making a weird SSL connection to Google. Then I thought of checking Facebook (BTW, FB is not my site, I am not Zuck :slight_smile: from two locations:

Here is a test against facebook.com from Dulles, using Chrome over DSL.
http://www.webpagetest.org/result/120208_9Z_d839c3a492712350c77b5f750dc10be9/1/details/

Notice that requests 14 and 16 in their waterfall view are SSL connections to IP addresses 72.14.204.104 and 72.14.204.120 respectively. These IP addresses are owned by Google, and the SSL connections timeout.

But I ran a similar test to the same Website from NYC , using the same parameters (Chrome over DSL). The results are interesting:
http://www.webpagetest.org/result/120208_SX_50479c50b381627d9c0f0508fac61e5f/1/details/

No weird SSL connections.

SJC seems to have the SSL timeouts as well though:
http://www.webpagetest.org/result/120208_6X_b5da738f21acd0917ed89a2f39c25b51/1/details/

EDIT: Sorry my last few lines didn’t make it for some reason earlier.

But I was a little curious as to why Chrome would behave differently at the NYC location (ie no SSL connections)

7

It’s possible that only some of the chrome agents have the SSL decoding enabled - I’ll take a look (with it disabled the ssl requests are completely invisible).