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.
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.
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)
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.
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.
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.)
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.
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?
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