I mean SPDY is here and almost every server can handle it already. (where can != is configured to by default) If google pulls features from HTTP-2.0 into SPDY-1.x in the next couple of months, what would be the benefit of anyone doing HTTP-2.0?
A clear case where a working and apparently perfectly well backwards compatible vendor-specific implementation worked so well that it actually might get to be an official standard.
Now if only we could have SSL with name based virtual hosts or much wider use of IPv6 so that SPDY will actually be useful for a wide range of server administrators.
We can: it's called SNI (http://en.wikipedia.org/wiki/Server_Name_Indication). Unfortunately browser support isn't quite there; recent versions the major desktop browsers do support it, but e.g. the stock Android browser does not (because Apache HttpClient does not).
I sure as hell could appreciate a new HTTP-standard, which was brought to the field by having professionals (maybe even IETF!) work together and reason about things publically, not just have Google hijack the process, dump shit out, saying "that's what we have implemented. if you want to compete with us, you will have to take this package", and then after the fact release some docs and claim it's open.
You know. SPDY just smells bad wherever you look. I'd like for the new HTTP protocol to be something you can trust
Source?
This is a good point, for instance the developers of Spdy don't actually compare it to HTTP pipelining. They don't measure the effect of 'head of line blocking', just assuming it is a major problem. They don't consider that the protocol performs worse than HTTP over satellite and similar links. Neither the design choices nor specific details have been vetted or backed up by real deliberations.
There are tons of ways a committee of experts could improve Spdy, but it looks like Google is just going to show up with their draft RFC and demand a rubber stamp.
But this is just typical Google. Even when they do work with committees they show up and for instance say 'add big integers to JavaScript or else' (the 'or else' being Dart).
Why is it "preemptive"? It seems more like a nonpreemptive push, right?
Does this mean keeping a background tab open uses a remote server's resources indefinitely? How can I as the server dev prevent unintentional DDOS?
So in the case you quoted, the server would also be able to explicitly tell the browser to start a new connection later. (It's not just a browser-to-server signal.)
Generally, most HTTP 1.1 (keepalive-aware) servers have a default timeout for those "persistent" connections[2][3] so this isn't actually a new problem specific to SPDY.
(Aside: simply consuming leaving open an idle TCP connection for later re-use doesn't necessarily imply that idle users will "DDOS" a server. Depending on the server software and OS, the cost-per-socket is low enough that many idle connections isn't actually a problem until you get to port and file descriptor limits — which, again, is already well-dealt with in plenty of other HTTP/TCP applications by using timeouts at all.)
[1]: http://www.chromium.org/spdy/spdy-protocol [2]: http://wiki.nginx.org/HttpCoreModule#keepalive_timeout [3]: https://httpd.apache.org/docs/2.2/mod/core.html#keepalivetim...
