Hacker News new | ask | show | jobs
by protobluffers 5023 days ago
I never liked SPDY to begin with. It always seemed to be gratuitously promoting a "new" protocol when many of the speed gains can be had from simply paying better attention to existing protocols, e.g. using pipelining for multiple resources from the same domain. A lot of the "slowness" of the web comes from ignorance and laziness, not lack of capable protocols. It was disturbing how much mindshare SPDY seemed to be getting just based on hype.

And TLS always seemed like a replacement for SSL, when what's really needed are _alternatives_ to the SSL model, not a GNU clone that proclaims it can do the same or better.

This is just my opinion. I apologise if it offends anyone.

Fortunately there are alternatives. You just have to look beyond the hype.

2 comments

You're confusing SSL and TLS with OpenSSL and gnutls. TLS is basically a revised version of SSL developed by the same groups and through the same processes as SSL. The GNU project subsequently created gnutls, which is an implementation of both SSL and TLS just like OpenSSL is - the only reason it's named after TLS and the older libraries are named after SSL is because the older ones predate TLS.
s/clone/revised version/
I'm not sure what motivates this comment... the issue at hand is certainly not a vulnerability in the SPDY protocol.
"CRIME works only when both the browser and server support TLS compression or SPDY"

If it would make more sense, then s/protocol/implementation/g or whatever you need to do to make sense of this.

How ever you choose to frame it, the targets are TLS and SPDY.

Huh? SPDY uses TLS. The target is basically "web browsers".
"web browsers" that support TLS compression or SPDY (which uses TLS compression)

It's quite possible to use a browser that supports neither. Indeed I'm using one right now.

Does the SPDY spec require TLS compression? IIRC, TLS is needed. Hence, SPDY+http compress+no TLS compression is workable, no? It's not ideal but would still work...