I am uncertain that I can easily troubleshoot the my Firefox SPDY woes any further, so tonight, I throw a test site up in the hope that someone else can solve my problem. I will make this available at https://test.spdybook.com:3000 (the SSL cert is invalid).
The unstable version of node.js is required for this. Happily, this means that I do not need to bother with SPDY-capable versions of openssl—the unstable 0.7 series is the first that will bundle a proper SPDY-capable version of openssl.
First, I download and install the latest unstable version of node.js:
cd ~/Downloads wget http://nodejs.org/dist/v0.7.8/node-v0.7.8.tar.gz cd ~/src tar zxf ~/Downloads/node-v0.7.8.tar.gz cd node-v0.7.8 ./configure --prefix=$HOME/local/node-v0.7.8 make make installNot only does the unstable branch of node.js include the correct openssl, but it also includes npm, making the process of getting up and running incredibly fast.
I already have node-spdy checked out, so I fetch my recent changes and switch to the spdy-v3 branch:
cd ~/repos cd node-spdy git fetch origin git co -b spdy-v3 -t origin/spdy-v3The rest of the install is similar to when I first got started with spdy/3 on node.js. I link this node-spdy package as "the" node-spdy that npm will install instead of downloading:
cstrom@li97-191> npm link npm http GET https://registry.npmjs.org/mocha npm http 200 https://registry.npmjs.org/mocha npm http GET https://registry.npmjs.org/mocha/-/mocha-0.10.2.tgz npm http 200 https://registry.npmjs.org/mocha/-/mocha-0.10.2.tgz npm http GET https://registry.npmjs.org/growl npm http GET https://registry.npmjs.org/debug npm http GET https://registry.npmjs.org/commander npm http 200 https://registry.npmjs.org/debug npm http GET https://registry.npmjs.org/debug/-/debug-0.7.0.tgz npm http 200 https://registry.npmjs.org/growl npm http GET https://registry.npmjs.org/growl/-/growl-1.4.1.tgz npm http 200 https://registry.npmjs.org/commander npm http GET https://registry.npmjs.org/commander/-/commander-0.5.2.tgz npm http 200 https://registry.npmjs.org/growl/-/growl-1.4.1.tgz npm http 200 https://registry.npmjs.org/debug/-/debug-0.7.0.tgz npm http 200 https://registry.npmjs.org/commander/-/commander-0.5.2.tgz firstname.lastname@example.org ./node_modules/mocha ├── email@example.com ├── firstname.lastname@example.org └── email@example.com ../../local/node-v0.7.8/lib/node_modules/spdy -> /home/cstrom/repos/node-spdyInstead of generating a new express.js site, I copy the one that I have been using locally:
➜ express-spdy-test scp -r app.js keys package.json public routes views linode:repos/express-spdy-testThere is not too much difference between this and a generated site (
npm install -g express; express express-spdy-test), but I do have a couple of large images in there that can push flow control in spdy/3 to the breaking point.
Now I complete the npm link of my local node-spdy package (it's just "spdy" in npm):
cd ~/repos/express-spdy-test npm link spdy ./node_modules/spdy -> /home/cstrom/local/node-v0.7.8/lib/node_modules/spdy -> /home/cstrom/repos/node-spdyI have to force install express.js (and its companion connect.js) since neither are warranted to run against unstable node.js:
npm install firstname.lastname@example.org --force npm install email@example.com --forceFinally, I can fire up the server:
node app Express server listening on port 3000 in development modeWhen I connect with Chrome to https://test.spdybook.com:3000, I am greeted with the invalid SSL certificate as expected:
After clicking "Proceed anyway", my spdy/3 conversation proceeds apace. Except...
The second image—the image incidentally with which Firefox was struggling—fails to load.
And, sure enough, the SPDY tab in
chrome://net-internalsshows that there is an error in there:
... SPDY_SESSION_RECV_DATA --> flags = 0 --> size = 1300 --> stream_id = 9 SPDY_SESSION_RECV_DATA --> flags = 0 --> size = 1176 --> stream_id = 9 SPDY_SESSION_CLOSE --> description = "bytes_read is 0." --> status = -100Gah! Did I ever try the most recent patch in Chrome or did I just assume that I worked? I don't know, but I will investigate that tomorrow. It seems at least plausible since the Firefox errors that I have been seeing were also on stream #9 (the second image). It seems likely that Firefox was not wrong after all.