Included here is the type, which is a SYN_STREAM. The Response class had been returning a SYN_REPLY in response to an already open SYN_STREAM (e.g. one that requested the homepage). Here I am trying to initiate a server push, hence the new SYN_STREAM. Also in there is the unidirectional flags as required by SPDY server push (there will not be a back-and-forth here, just push from the server). The new stream ID and the associated ID are set in the constructor.

(Actually, after double-checking in the enums.js file, I find that it is CONTROL_FLAG_UNIDIRECTIONAL)

Another requirement of the server push spec is that the URL is set in the SYN_STREAM. Like the stream ID and associated stream ID, the headers are currently being assigned in the constructor. For this spike, I will explicitly set the URL to the stylesheet being used. If this works, the stylesheet will make its way into the browser's cache—ultimately preventing the browser from needing to request it. So, the header:

This method writes the just crafted header (unless it has already done so). Then it builds the DATA frame and writes it back to the connect stream.

Last up tonight it doing a little work back in the Response class. The server push will be initiated back in the Response class because server push needs an associated stream ID in order to be valid. With that in mind, I define the previously stubbed Reponse#createPushStream method:

The control frame (from the original browser request) will be sufficient to determine the associated stream ID and the connect stream will provide the transport for the server push.

Tomorrow I will add the actual data and (without a doubt) perform quite a bit of debugging because I have really played fast and loose with this code tonight as I simple tried to wrap my brain around it. Even so, I am pleased with the progress tonight. I feel as though I am close to having a workable server push in SPDY.