The browser reports a simple connection refused. Refused because the server crashed.

That is not making it anywhere near node-spdy. The backtrace seems to indicate that it is failing somewhere in the SSL/TLS code. Ugh.

I am not sure where to even begin troubleshooting this one, so I try starting an incognito session—to no avail. I try reloading and waiting a very long time—to no avail.

What ends up fixing it is restarting the browser completely. Not too big a deal since Chrome remembers tabs and windows, but... still. I would prefer a better resolution than the old windows three finger salute. For now, I push that to the back of my mind in the hopes that it has not derailed me too much tonight.

Back in my push-stream branch, I move my pushStuff() method after the SYN_REPLY response has gone out:

After restarting the server, I access the test site again. This time, I find:

Nothing. In this case, nothing is actually progress. Last night, when I tried accessing the server, I was greeted with a lovely SPDY session error message. It seems that I am no longer causing a SPDY error. Something is still going wrong though.

This is a spike, so I am hard coding the stream ID to 2 (server initiated SPDY streams are all even). The associated stream ID is 1, indicating that the push began as a result of the request in stream #1. Also of note is that the URL of the resource is included in the pushed data. Without the URL, the browser will not know how to cache the data, which would render the server push useless.

The two push stream data packets indicate that there are 20 bytes/octets of data and that there is nothing else on this stream.

Next up, Chrome receives two data frames on the original SYN_STREAM #1. This is the original request for the HTML resource itself:

After about ten seconds of waiting for the page to respond, I escape / stop the request. Looking at the results in Wireshark, I see a lot of green (decrypted packets):

Green is normally a good thing. It means that there are lots of little SPDY frames moving about doing their thing. The problem here is that most of the SPDY frames are moving about after the 10 second mark—after I escaped the request.

The first packet through is the SYN_REPLY to the request for the homepage:

Here, I also include the ASCII representation of the data to show that this is the fake stylesheet that I am trying to push. The stream ID for this data frame is 2 (the fourth octet), so this is definitely from the push stream.

The stream ID is 1 (the reply to the original request for the homepage). There is no data in the reply (length zero), but this is not what indicates that this is the final data frame for this stream. Rather the flag of 0x01 indicates DATA_FIN.

What is missing here is a similar DATA_FIN frame for the push stream. The DATA_FIN flag is set, but perhaps that is not sufficient. Perhaps Chrome needs a separate DATA_FIN frame nowadays. I will pick up my investigation there tomorrow.