Author here: Yes, the README is aspirational, its a checklist for myself. I put the STATUS line there for everyone else, but it appears no one actually reads it. (Heck, not one other person on HN actually tried it out, because it sure as heck doesn't work yet).
I hadn't put any publicity out about the code yet, I had just pushed it up to github a few days ago because I wanted to move the code around to some other machines, I didn't expect anyone to pick it up.
seems to me that one of the main ways SPDY speeds things up is by sending of hints and attached content all in one connection. If you are proxying over http, you can't have access to any of the domain specific information, and thus you won't see hardly any of the SPDY benefits
I'm not sure if that's one of the most important parts of SPDY. Multiplexing multiple streams over one TCP connection and differentiated quality of service (some streams have higher priority than others) still work perfectly in this kind of system, and provide huge benefits.
I don't know the details of how SPDY works, but could this proxy be taught some custom HTTP headers (X-SPDY-Hint: /static/site.css) which can be trivially sent by the proxies application and could be used to enable advanced SPDY features?
I'm not sure what you mean by lack of domain specific information and hints. A SPDY proxy shifts the expensive aspects of HTTP from high latency client-server connections to proxy-server connections where they are comparatively cheaper due to lower latency.
Exactly; my take is clients connecting over Internet via SPDY to a gateway that uses HTTP keep-alive over LAN to your servers confers most of the advantages of SPDY.
SPDY improves upon keep-alive by reducing the number of connections that need to be created and in eliminating blocking.
SPDY reduces the number of persistent HTTP connections between client and server from around six (depending on browser) to one. High latency connections increase the time required to create these initial connections, and round trip times have not been consistently declining despite bandwidth improvements.
HTTP requests over each keep alive connection are blocking, i.e. the server must response before another request can be made. SPDY addresses this blocking by multiplexing requests and responses. Note that the head-of-line blocking that jganetsk mentioned is a separate issue.
Imagine nginx spoke SPDY. Now replace nginx with this new proxy. Now imagine that its talking keep-alive HTTP on the inside.
The gateway can even send the incoming requests between many servers and aggregate the results and send them back to the client out of order, as per SDPY
The overhead of a reverse proxy in terms of latency is essentially zero. Just think about it like this: with HTTP sometimes you need to wait for some extra packages to go back and forth. These packages need to travel over the Internet. You can trade in these packages with packages, which travel though your loopback device. Seems like a good bargain to me.
Also to make benchmarks, it helps to have a working product first.
SPDY wouldn't just help on an isolated benchmarkable level; if the Internet en masse significantly decreased the total number of TCP connections, there would be a benefit to the herd. Congestion control would just work better. It's hard to measure such things.
