Firefox 13 Beta Turns On the ‘SPDY’(webmonkey.com)
webmonkey.com
Firefox 13 Beta Turns On the ‘SPDY’
http://www.webmonkey.com/2012/04/latest-firefox-beta-turns-on-the-spdy/
7 comments
Microsoft has submitted a proposal that is interesting for a few reasons. The requirement for encryption is optional and also the API/framing is closer to Websockets.
http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mo...
If encryption is required, I can see many complaining about the burden of certificates. Will this finally drive an alternate solution such as Moxie Marlinspike's Convergence project to help us do away with the certificate authorities? Also, I can see a huge increase in the number of IP addresses unless some serious progress is made with SNI. On the otherhand, that might finally open the floodgates for widespread IPv6 adoption.
http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mo...
If encryption is required, I can see many complaining about the burden of certificates. Will this finally drive an alternate solution such as Moxie Marlinspike's Convergence project to help us do away with the certificate authorities? Also, I can see a huge increase in the number of IP addresses unless some serious progress is made with SNI. On the otherhand, that might finally open the floodgates for widespread IPv6 adoption.
That proposal has a pile of problems: http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy...
Yes it does. As does the original proposal and I mentioned some issues in my post.
The Tabs-on-demand feature that the article mentions... isn't that the "don't load tabs until selected" feature that has been around since FF9?
nah it will load tabs that you open in the background without that option, even in FF13
but if you restart the browser, it won't, ONLY for the tabs it restores at startup.
Means basically if you open a tab via click or contextual menu and u don't have "only load tabs when selected" it WILL load the tab. But when you restart the browser (or start) with your 100tabs, it will only load the first one. Before that itd both be slow if you had a bad connection and be slow (obviously no browser can instant-render 100 pages)
Means basically if you open a tab via click or contextual menu and u don't have "only load tabs when selected" it WILL load the tab. But when you restart the browser (or start) with your 100tabs, it will only load the first one. Before that itd both be slow if you had a bad connection and be slow (obviously no browser can instant-render 100 pages)
I'm currently downloading FF13 only because of that feature. I always have 100+ tabs open, and oftentimes, when a browser is "full" (i.e., too many tabs) I switch to another browser until I have time to clean up the mess. There were situations where Chrome, Safari, and Opera were "full".
Really looking forward to this new feature.
I'm a little unclear on how SPDY works. Is it correct that it only speeds up HTTPS connections? Does that mean you need to redirect traffic for:
http://example.com/
to:
https://example.com/
before you know if the client has SPDY support enabled?
http://example.com/
to:
https://example.com/
before you know if the client has SPDY support enabled?
No. If both the browser and server support SPDY, all http: and https: URLs will go over SPDY, and SPDY is encrypted. So even http: URLs that look unencrypted are actually being secured "by accident".
This is not true. Only HTTPS URLs get SPDY. Perhaps you're thinking of HTTP Strict Transport Security, which transforms HTTP URLS to HTTPS on the client. You can see whether you're getting SPDY or not (in Chrome) at chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
One reason for this is that proxies and other buggy/evil bit-twiddlers in the path of your connection don't understand SPDY, so the only way to punch SPDY through them is to use a protocol they're not allowed to meddle with.
One reason for this is that proxies and other buggy/evil bit-twiddlers in the path of your connection don't understand SPDY, so the only way to punch SPDY through them is to use a protocol they're not allowed to meddle with.
I can't find any documentation to corroborate that. The draft 2 spec mentions HTTP several times: "...it should be used in preference to HTTP/HTTPS. ... all HTTP requests can "piggyback" on an existing SPDY session. ... all future http requests to that host port pair should use the SPDY session rather than opening a new HTTP connection." http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra... (Curiously, the deployment section is completely missing from draft 3 and the IETF version.)
If Chrome does something different, I wonder why.
If Chrome does something different, I wonder why.
Interesting, I hadn't seen that part of the spec. Since it was removed from later drafts, perhaps there was some objection. It's clearly not implemented on google.com.
Edit: Chrome and Firefox do appear to contain support for the Alternate-Protocol header described in Draft 2 of the spec, so it does appear possible to configure your server to tell them to send HTTP:80 requests over SPDY:443 instead. However, this does not allow one to use SPDY without encryption, and it does not add significant security to plain HTTP since the first request is still unencrypted.
After further research, while Alternate-Protocol is implemented, it appears that it might not end up being standardized due to security concerns. I wouldn't rely on it.
Edit: Chrome and Firefox do appear to contain support for the Alternate-Protocol header described in Draft 2 of the spec, so it does appear possible to configure your server to tell them to send HTTP:80 requests over SPDY:443 instead. However, this does not allow one to use SPDY without encryption, and it does not add significant security to plain HTTP since the first request is still unencrypted.
After further research, while Alternate-Protocol is implemented, it appears that it might not end up being standardized due to security concerns. I wouldn't rely on it.
It looks to me like it's just talking about HTTP the protocol, as in GET, POST, etc., and saying that you can reuse a SPDY session instead of opening a new connection — it's not saying you can use SPDY over unencrypted HTTP.
As I said, SPDY always runs over TLS. What we're debating here is whether you can request an http: URL over a (secure) SPDY connection. I see no reason why not and it should be faster, yet it appears that this isn't being done.
We removed the alternate-protocol stuff only because we thought it needed more work. It is implemented in chrome, so you can try it, but we're still considering how we'll deal with it going forward.
Kinda crummy article to mention that SPDY is actually present in earlier Firefox versions, but just turned off. How about telling us how we can turn it on?
I looked it up: In Firefox 11 and newer, punch in about:config in the URL bar, then find network.http.spdy.enabled and turn it on.
Basically everything is in about:config, and it has a search function. I don't think it's crummy of the article to not mention the exact details.
Shame there isn't a SPDY test site I can find. spdytest.com, by the way, does not run over SPDY. It's a plain HTTP/HTTPS site.
Google and its suite of apps all use SPDY. Works great on Firefox Aurora. Get this extension: https://addons.mozilla.org/en-US/firefox/addon/spdy-indicato...
FWIW, a screenshot: http://static.deno.pl/pub/hn/spdy-firefox.png
FWIW, a screenshot: http://static.deno.pl/pub/hn/spdy-firefox.png
Most of Google apps use SPDY, but for some reason, ipv6.google.com does not.
I would love to have an old school version. Slim and "let me design it the way I want".
You mean, of the browser? You could try uzbl; the core part doesn't even have an URL bar: http://www.uzbl.org/
What exactly do you want taken out? I think if you hop back to when FF was truly slim (say, v1.5) you'll discover the Good Ol' Days(tm) weren't quite as rosy as you thought.
[1] https://twitter.com/#!/nginxorg/status/192301063934705665