I've attached a net-internals export covering the loading of the test page until the CSS file fails. This is from 56.0.2898.0 (Developer Build) unknown (64-bit) on Ubuntu in Incognito mode.

Deleted: 653329-net-internals.json 345 KB

653329-net-internals.json 345 KB View Download

There's a couple things here:

It looks like attempts to connect to the IPv6 endpoint is timing out (Event 1337, Event 1401, 1404, 1407). Similarly, SSLLabs sees this - https://www.ssllabs.com/ssltest/analyze.html?d=www.w3c-test.org&s=2001%3a470%3a8b2d%3a804%3a53%3a0%3a133%3a0

To your failure case, event 1433 shows the attempt to connect to the server, which is bound to the socket 1438. In that case, we sent a TLS client hello, but after 30 seconds of no reply, the server just dropped.

What's not clear to me is why our socket pool logic is not coalescing some of these requests, even in HTTP/1.1 mode. I may be missing something obvious here, but I am surprised to see multiple connect jobs kicked off for HTTP/1.1 sockets when the pool has available sockets that have finished.

Matt, Eric, Randy: You're all much better at NetLog reading, am I missing something here for why Event 1429 wouldn't re-use an existing socket from the previous Event 1353/1356/1359/1362?

Looks to me like while the server does not use "Connection: Close", it (the server) is actually hanging up each socket after a single request, so there are no sockets around to reuse.

Oh duh, thanks, that should have been obvious.

Given that the server is self-reporting as "BaseHTTP/0.3 Python/2.7.12", I'm wondering if it's just one of the many known issues with Python's HTTP server and handling multiple requests (that is, similar to the issues we've heard re: socket preconnect), in which case, this is mostly a server issue (short of disabling preconnect; FF may not be doing it as aggressively or selecting an older socket first)

Is there any good way in the net-log to know if we have existing preconnected sockets at the point we make the request that times out?

Ohh...Right...This may have something to do with preconnect in combination with Python's HTTP server sucking.  We have two other connected sockets to the server which are just hanging out in the TCP socket pool, one privacy mode, one not.  The pm one predates the hung socket by a fair bit.

We're not trying to negotiate SSL on either of those two sockets, curiously.  I'm not sure why that is, I don't think they're backup connections, there are no cancelled SSL requests to account for them, either.

SOCKET 1428 is the pm socket in questions (Just look at type:SOCKET, and look at the white ones, though the problematic socket wouldn't necessarily be white)

As far as next steps for this bug:
- WontFix (and just say the internet is awful)
- Verify if it's preconnect
  - If it is, do we have any thoughts on what we might do differently?
  - If it isn't, do we have any thoughts on what else it could be?

I see all options viable, but curious whether I'm going to be tilting at windmills to suggest one or the other :)

From the right account, this time...

I'm kinda curious why we have SSL sockets that haven't negotiated a connection hanging out in the socket pool...Fixing that wouldn't really fix this particular issue in general, though it may fix this particular case.

Actually, it wouldn't fix this case, the non-PM connection would still be stuck behind the privacy-mode one. May alleviate it in some cases, though.

Archiving old bug