9 ms·
HTTP 2.0 First Draft Published
- jgrahamc 14y agoPersonally (i.e. not speaking on behalf of my employer) I'm not terribly keen on SPDY being HTTP 2.0. It fixes HTTP/1.1 pipelining by adding a layer of binary complexity to a protocol that has succeeded by being simple and textual. Also, it's a sort-of-layer because it really is dependent on details of HTTP (such as the existence of headers) to operate so it is not an independent layer. In networking I'm much happier when layers are independently specified. Also, I think the implementation of header compression is poor because it uses a fixed dictionary that is based on current HTTP headers. There's no provision for negotiation of this going forward. It would be better if the compression dictionary were negotiated on session creation. Notice how the dictionary has been updated between standard drafts. Once it's in the standard updates will not be possible. And SPDY requires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. Unless SSL certificates are suddenly free and trivial to deploy then that would make HTTP 2.0 complex. I would much rather see a proposal to change HTTP so that pipelining works, using textual headers and not require TLS.
- kibwen 14y agoHave you tried getting your voice heard in the standardization process?
- tbrownaw 14y agorequires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. Unless SSL certificates are suddenly free and trivial to deploy Get the browser vendors to stop being idiots, and treat self-signed SSL connections as identical to plaintext connections. Or even better get them to implement a notary model [ http://perspectives-project.org http://perspectives-project.org ] (as a default rather than an extension), that doesn't allow for a single insecure CA to break the security of the entire web.
- revelation 14y agoI never thought about it from that angle. You are right, it makes no sense for browser vendors to display a big fat warning page because someone signed a certificate himself while they never let you know that 90% of the websites you use are transferred in plain-text over a wholly untrusted network.
- zobzu 14y agoNot exactly. The fat warning is there so that you don't get a false sense of security by seeing a little lock. But then again, we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". I wonder how much verisign pays some of us.
- tptacek 14y agoVerisign did not pay Mozilla to make it harder to click through the broken certificate warning.
- zobzu 14y agoDo you mean that you can't bypass the certificate warning anymore in Firefox? (or will not in the near future) If that is so, what is your reasoning behind it?
- danielweber 14y agowe're now moving to a "if its self signed, you can't access the site, you can't bypass the check even". wait wait wait what? I am currently in a space where we have to deal with self-signed certificates all the time. I fully accept that people like me will have to deal with more hassles from this so that people don't get their paypal accounts hijacked as easily. But I've yet to find out that I simply cannot connect to a site with a self-signed certificate.
- zobzu 14y agoHave a look at http://www.imperialviolet.org/2012/07/19/hope9talk.html http://www.imperialviolet.org/2012/07/19/hope9talk.html for a glimpse of the future:)
- paulsutter 14y agoIf you don't want to deal with certificates just keep using HTTP 1.1. If you want the speed and security improvements of 2.0, certificates will get cheaper and easier to obtain. Most of the certificate authorities' costs are one-time (validating identity). Issuing subsequent certificates costs them nothing. Pricing will adjust accordingly with increased demand (and in some cases already has). A fixed dictionary for header compression is a lot better than no compression dictionary. Negotiation would be added complexity/latency. Sure you could argue either way but it doesn't seem like a big deal. Google has done a great job on SPDY. It's proven at scale and performs really well. Making it a standard is a great move.
- fusiongyro 14y agoPoul Henning-Kamp said many of the same things when this came up last time, and I agree with both of you. https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html IMO, a HTTP 2.0 standard based on SPDY is a small but meaningful illustration of the divergence from an idealistic egalitarianism to an oligarchy of a handful of huge organizations. The issues at stake here are basically monetary for Google and a few other companies. There's very little technical finesse here despite the added complexity, and certainly little to no reimagining or benefits to the vast majority of independent site operators or web developers.
- salmanapk 14y ago> Unless SSL certificates are suddenly free Oh god why so many people dont know about StartSSL.com. They've been offering free SSL certificates since quite some time.
- bickfordb 14y agoIt seems like it would be a lot simpler to fix the current pipelining infrastructure (already in the spec but not used?) and tag pipelined request/responses with request IDs.
- sophacles 14y agoI somewhat agree, however instead of making pipelining work in HTTP, they should remove it altogether, and focus the HTTP protocol to just the request response structure/headers. Then, create a second protocol - say HMWP (HTTP Multiplexed Wire Protocol) (not a real protocol, I just made that up) that focuses on pipelining, server-push, header compression, etc. This layering approach really feels more "internetty". It also would allow independent development in terms of network optimization and application handling. This split would also help adress conflicts between Cache/Proxy/Balancer developers and Application developers.
- mtgx 14y agoMy favorite part about it is that everything will be encrypted by default in the future.
- deelowe 14y agoAnd require SSL certs, which cost how much again? It's quite an expense for hobby sites, non-profits, and such.
- selectnull 14y agoLike most (all?) digital products, the price of SSL certificates will converge to zero with higher usage. So mass adoption might be beneficial after all.
- zobzu 14y agoI believe the Internet should stay free, and making your own website should certainly stay free. Right now, you don't have to have a domain. You don't have to pay for a SSL certificate. You don't have to pay for hosting. The only thing actually need you pay for is the link to the ISP. And it's not like there weren't better, free alternatives either. Ultimately it's not about the price tag. It's about having a third party controlling your stuff. It's more about freedom than free as in beer.
- JoachimSchipper 14y agoIt took me a minute to figure out that "what do you mean, not free? Surely wordpress will just buy a *.wordpress.com certificate?" was not what you're going for.
- zobzu 14y agoWell yeah, unless you own *.wordpress.com, the certificate and domain belongs to wordpress.com, not you. You're in their hands.
- 14y ago
- NathanKP 14y agoDoes anyone else have any experience setting up SPDY on a web server? Since SPDY is already supported by Chrome and Firefox, I'd be interested in at least experimenting with it if there is an Apache or Nginx based solution which is stable enough to work in production. Of course I would also need to serve old style HTTP for those that are using a browser which doesn't support SPDY but if there is a way to serve SPDY to those who can support it I'm all for trying it out.
- jolan 14y agoThere's mod_spdy for Apache 2.2 developed by Google employees: http://code.google.com/p/mod-spdy/ http://code.google.com/p/mod-spdy/ And a spdy patch for nginx from one of the main nginx developers: http://nginx.org/patches/spdy/ http://nginx.org/patches/spdy/ Wordpress and CloudFlare both use the nginx patch so it should be production ready. I use mod_spdy and haven't had any problems.
- HerraBRE 14y agoI think it will be quite tragic if HTTP 2.0 ends up being a binary protocol. The discoverability and readability of the basic text based Internet was, in my opinion, one of its most fantastic qualities. It meant that as a young hacker I could just look at things and see how they work and then progress to learning and experimenting by writing very naive partial implementations of said protocols. I am not sure the bits saved justify the obfuscation of everything.
- wildranter 14y agoAnd here we go again, another design by committee to haunt us. If this piece of crap sticks we all will have to keep using HTTP 1.1 which by the way isn't that bad. First web sockets, and not this. Just great.