9 ms·

HTTP/2.0 – Please admit defeat

323 points by hungryblank 12y ago

kolev 12y ago
Well, SPDY might be a "prototype", but it's solving real problems today - I care less if it's perfect or not, if it solves all problems or not, as long as it's easy to implement, has a decent footprint, and offers significant improvements over HTTP/1.1. An imperfect working prototype is better than a perfect blueprint that materializes in distant future where problems and environment can differ greatly.
- adamtulinius 12y ago
  Well, according to this mail from the Jetty-team, it doesn't seem like http/2.0 is easy to implement at all: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0807.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... Furthermore, if http/3.0 is already being discussed, why not just skip http/2.0 entirely, and live with the current http/1.1+SPDY situation until the work towards a new standard for http is actually done?
  - canadev 12y ago
    What does "LC" mean in that post?
    - Tomte 12y ago
      "Last Call". See http://datatracker.ietf.org/doc/help/state/draft-iesg/ http://datatracker.ietf.org/doc/help/state/draft-iesg/
  - kolev 12y ago
    Wait 5 more years? No thanks!
- justincormack 12y ago
  But you can continue to use it even if it is not the standard as it has widespread support.
- deleted 12y ago
  [deleted]
- prohor 12y ago
  But then you need to support 1.0, 1.1, 2.0 and 3.0. I'd rather wait a bit to avoid need to support yet another version. I can bet every new version of HTTP will cost millions of dollars across the industry. It is not agile where you just drop in a new increment. This is the base everybody need to support then and you won't be able to stop support in foreseeable future.
  - jacquesm 12y ago
    > I can bet every new version of HTTP will cost millions of dollars across the industry. That would be a fairly easy bet, but I doubt anybody would take the other side. My own estimate at rolling out a major HTTP protocol revision across the industry would be in the 100's of millions. Take into account that we have approximately 750 million web sites and 3 billion clients.
stormbrew 12y ago
I am so glad there is at least one prominent name advocating this line, because I feel like this quote from another IETF discussion is becoming more and more relevant: > Is there an IETF process in place for "The work we're doing would harm the Internet so maybe we should stop?" - http://www.ietf.org/mail-archive/web/trans/current/msg00238.html http://www.ietf.org/mail-archive/web/trans/current/msg00238.... HTTP/2.0 has been rammed through much faster than is reasonable for the next revision of the bedrock of the web. It was always clearly a single-bid tender for ideas, with the call for proposals geared towards SPDY and the timeline too short for any reasonable possibility of a competitive idea to come up. There has never been any good reason that SPDY could not co-evolve with HTTP as it had already been doing quite successfully. If it was truly the next-step it would have been clear soon enough. All jamming it through to HTTP/2.0 does is create a barrier for entry for similar co-evolved ideas to come about and compete on even footing.
- youngtaff 12y ago
  PHK has always been skeptical of HTTP/2 & SPDY He wants radical change in the protocol but when given the opportunity submitted a (by his own admission) half baked proposal - there's also the question of what a protocol like HTTP/2 means for his product. Although HTTP/2 started from SPDY it has evolved, and in different ways e.g. see the framing comments from the thread the OP links to. We need a better protocol for the web now, yes we could wait around longer for more discussion but where did that get us with HTTP/1.1 - I'd be quite happy if IETF had just adopted SPDY lock, stock and barrel (and no I don't work for Google)
  - stormbrew 12y ago
    I'm aware that he's always been skeptical, I saw his posts as my own excitement over the idea of HTTP/2.0 died on the vine from being subscribed to the WG mailing list. There has never and will never be a point in time where we don't need "a better protocol for the web now." The issue is that canonization was unnecessary, adoption of spdy has been progressing fine without it. And HTTP/2 diverging significantly from spdy does not inspire confidence, either. Rather it just reminds of a famous xkcd [1]and again begs the question of whether trying to turn spdy into http/2 even manages to achieve any of the goals the process was setting out for. The whole thing just seems like a big fat SNAFU. [1] http://xkcd.com/927/ http://xkcd.com/927/
taspeotis 12y ago
Related [1]: Wired: How has your thinking about design changed over the past decades? Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled programmers to “throw the first version away,” then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised. [1] http://www.wired.com/2010/07/ff_fred_brooks/ http://www.wired.com/2010/07/ff_fred_brooks/
- orkoden 12y ago
  This is true for application software you write. Standards work differently.
- bostik 12y ago
  I am not sure how well that applies to a protocol that is supposed to be codified in every single browser, web server and utility library in the world. The iteration cycle will be slow, and improvements can not happen overnight. Now, if the name was something like HTTP/1.8-alpha it might be a different thing. At least then it wouldn't carry the label of the "next big thing for everyone". It's sad, but names (and branding) do matter. Forcing a known-broken implementation upon the world is not exactly good engineering.
  - twic 12y ago
    WebSockets went through a series of iteration cycles like this. It wasn't entirely smooth sailing, but it seems to have worked out.
  - wmf 12y ago
    Google can iterate on SPDY and QUIC by just releasing new versions of Chrome, which is where all the knowledge behind HTTP 2.0 came from.
    - dsl 12y ago
      This is often overlooked as the single biggest failing of SPDY... its a protocol designed to work well for Google, which operates completely differently from every other web property. Google in-houses everything so a single fast multiplexed connection to a single server makes sense. Every other website has external content, ads, like buttons, etc. and you end up having to spin up 30-40 independent SPDY connections, eliminating all benefit.
jballanc 12y ago
I think this (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0816.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...) follow-up makes a valid point: > In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I don’t believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody else’s problem. If we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past. That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.
- pjc50 12y ago
  The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.
  - skrebbel 12y ago
    So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel. I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.
    - gtirloni 12y ago
      Looked like a good idea until you mentioned JavaScript. Bummer.
chacham15 12y ago
I think that one of the best things about HTTP/1.0 (and to a lesser extent 1.1) is its simplicity. The reason, to me, that that simplicity is so vital is because it has fostered large amounts of innovation.
maaaats 12y ago
What an awful way to try and get a point across. An aggressive tone and negative words baked into every other sentence, making the statements very loaded. There's probably a lot of missing context from viewing only this link, though.
lerouxb 12y ago
I think it makes sense to take the time to get it right. Every version of HTTP will effectively have to be supported by just about every server and client forever or otherwise the web will break. An incredible aspect of the web is that Tim Berners-Lee's first website back at CERN still works in modern browsers. Same with things like basically the entire Geocities archive. When it gets to core infrastructure like HTTP you can't just iterate quickly and expect the entire internet to constantly upgrade along with you. What works for early stage lean startups won't work here.
zhyder 12y ago
Interesting response from the WG chair: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0820.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... An aside: I find it odd how HN users jump to agreement when a link to a single mailing-list message is posted, ignoring other discussion on the thread. I think it's because the UI makes it hard to see the rest of the conversation (unlike -say- the comments UI on HN itself)
higherpurpose 12y ago
I'm in favor of dumping HTTP/S and using a faster and more secure (by default) Transport protocol altogether. Post Snowden revelations we should be focusing our energy on that, rather than continuing to hack around this old protocol to make it faster and more secure.
- marios 12y ago
  MinimaLT [1] comes to mind. Minimal latency through better security sounds very appealing, especially when it's not a marketint trick but a paper signed by people like DJB. The way I see it though, is not only to have a protocol, but how to get adoption. Especially when you're talking about network protocols, you need rock solid stacks in all major operating systems which is not an easy feat to accomplish. [1]: http://cr.yp.to/tcpip/minimalt-20130522.pdf http://cr.yp.to/tcpip/minimalt-20130522.pdf
brianpgordon 12y ago
I haven't been following the development of HTTP/2.0. What are the most egregious "warts and mistakes" in SPDY?
- fredliu 12y ago
  Mobile is one of them, although OP's arguments are valid as well. (http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf) Also, among many other things: every thing over SSL. Single Connection. Also, less of a technical problem, but as many already mentioned, too complicated as compared to plain text human readable HTTP 1.x
  - zobzu 12y ago
    also ssl everywhere without authentication by default. ie slower, encrypted, but not actually safe.
justincormack 12y ago
There is another interesting thread about internet of things http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should not have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others." http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0604.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."
- youngtaff 12y ago
  Pretty sure every ecommerce site will benefit from deploying HTTP/2 (although their tendency to fill sites full of third party components may reduce some of its benefits)
  - justincormack 12y ago
    Well the complexity makes it hard to build a performant server. https://groups.google.com/forum/#!searchin/mechanical-sympathy/http/mechanical-sympathy/CWyAD-oF9Uw/ycO0vxGqMvsJ https://groups.google.com/forum/#!searchin/mechanical-sympat...
  - fredliu 12y ago
    Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.
sebcat 12y ago
It should be noted that the sender of this e-mail is Poul-Henning Kamp, known among other things for another e-mail from back in the day (relatively speaking): http://bikeshed.com/ http://bikeshed.com/
quasque 12y ago
Would it be accurate to suggest that the rushing of Google's SPDY, as HTTP/2.0, through IETF standardisation is roughly equivalent to the situation a few years ago when Microsoft pushed Office Open XML through as an ECMA standard? Or is that just a huge mischaracterisation?
- marcosdumay 12y ago
  That's a huge mischaracterization. There are a few different implementations of SPDY, and a clear use case where it applies. Also, it's a clear standard, made for being used. What's happening here is that there is a group of very active people that create most of the software we use on the web, and have a use case they want to support. At the same time, there are lots and lots of people that are not as active, with a huge amount of use cases that will be hindered, but since they are not active, they have very little voice.
  - quasque 12y ago
    Thanks for the explanation, I haven't been following the progress of SPDY so I'm not familiar with the detail. What use cases would be hindered by this new standard?
    - marcosdumay 12y ago
      There are people complaining that it will break things because it's binary, that they can't have mandatory encryption, and that it's just too complex to fit in limited resources. There are probably other complaints that I didn't see. I've never read it in enough depth to verify those claims, but the response from the standard group is always "then use HTTP 1.1", what is as a non-solution as it gets. SPDY was great exactly because it was not the standard, it was an extra option, available if everybody agreed to it. Call it HTTP 2, and it will become mandatory in no time. IETF calling it optional won't change a thing.
mantrax5 12y ago
You know what we need, we need to pick one of those people and give 'em one day to invent HTTP/2.0 and it'll be a better spec compared to letting them all "decide" together by nerd-fighting each other into eternity. No standard is perfect, but the worst standard is no standard. Make up your fucking mind already.
gioele 12y ago
To put the comment and its author in context, Poul-Henning Kamp is the main developer of Varnish, a widely used high-performance standard-compliant HTTP cache. PHK has experience of HTTP both from the server point of view (the main job of Varnish is acting as a fast HTTP server) and from client point of view (Varnish acts as client to the slow upstream HTTP servers). As a side note, he also refrained for years from adding TLS support to Varnish after his review of OpenSSL and SSL in general (see https://www.varnish-cache.org/docs/trunk/phk/ssl.html https://www.varnish-cache.org/docs/trunk/phk/ssl.html ).
- ruben_varnish 12y ago
  Good one. More context on the ideas and proposal Poul-Henning has put on the table: http://phk.freebsd.dk/words/httpbis.html http://phk.freebsd.dk/words/httpbis.html
cwp 12y ago
Sounds to me like the real problem is lack of IP addresses, and the best strategy would be to hold off on updating HTTP and work on IPv6 ubiquity first. I can see why Google went a different route, but we don't all have to follow.
phkamp 12y ago
I'm here in case you want to ask me anything. Poul-Henning
- acdha 12y ago
  For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over. http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0833.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.
  - phkamp 12y ago
    I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason. If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP. Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause. And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol. Nobody seems to have heard the expression "Festina Lente" in this WG.
    - throwaway7767 12y ago
      If I understand your argument correctly, you are opposed to oppurtunistic encryption as there is no identity validation, as it does not improve privacy. But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that? (I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)
themgt 12y ago
A much better comment to link to would have the grandparent, by Greg Wilkins from Jetty, who gives a lot more substance and context to the debate: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0807.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... It does seem a little shocking that the WG chair is proposing last call while still there's serious discussion of things like dropping HPACK.
josteink 12y ago
Just like they admitted that XHTML 2 was a mistake and scraped it, I feel they should do the same with this nonsense. Nothing about spdy or http2.0 sparks any sort of confidence with regard to proper robust protocol design, keeping things simple nor properly separating concerns.
- haberman 12y ago
  It's funny that you mention XHTML 2, because I think it demonstrates the opposite of what you are arguing. XHTML 2 is a lot more like what PHK is proposing: an attempt to "rethink" HTML, come up with something simpler, revolutionary rather than evolutionary, "The Right Thing." It was an attempt to reinvent the space from first principles, and had lots of ideas that were theoretically good but unproven at large scale. When that went nowhere, the world settled on HTML5: evolutionary, incremental, and based on standardizing existing practice. Much less sexy, but more useful in practice. There is a time and a place for bold new ideas, but a standards body designing v2 of a protocol isn't it. Standards are for codifying proven ideas. When standards bodies try to innovate you end up with XHTML, VRML, P3P, SPARQL, etc.
- dragonwriter 12y ago
  > Just like they admitted that XHTML 2 was a mistake and scraped it But "they" (the W3C) didn't do that when people were just complaining about issues with the XHTML 2.0 approach, they did it after a competing approach was developed via an extensive, multi-year process through an outside group (WHATWG), and even then only that after a short period when both approaches were the focus of official W3C working groups. They didn't adopt a "this is limited, lets throw it away and start over" approach as the original article here calls for with regard to HTTP/2.0.
alexnewman 12y ago
It's not perfect so start over. Seems like the definition of why v2 is always so hard.

323 points by hungryblank 12y ago

kolev 12y ago

Well, SPDY might be a "prototype", but it's solving real problems today - I care less if it's perfect or not, if it solves all problems or not, as long as it's easy to implement, has a decent footprint, and offers significant improvements over HTTP/1.1. An imperfect working prototype is better than a perfect blueprint that materializes in distant future where problems and environment can differ greatly.

adamtulinius 12y ago
Well, according to this mail from the Jetty-team, it doesn't seem like http/2.0 is easy to implement at all: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0807.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... Furthermore, if http/3.0 is already being discussed, why not just skip http/2.0 entirely, and live with the current http/1.1+SPDY situation until the work towards a new standard for http is actually done?
- canadev 12y ago
  What does "LC" mean in that post?
  - Tomte 12y ago
    "Last Call". See http://datatracker.ietf.org/doc/help/state/draft-iesg/ http://datatracker.ietf.org/doc/help/state/draft-iesg/
- kolev 12y ago
  Wait 5 more years? No thanks!
justincormack 12y ago
But you can continue to use it even if it is not the standard as it has widespread support.
deleted 12y ago
[deleted]
prohor 12y ago
But then you need to support 1.0, 1.1, 2.0 and 3.0. I'd rather wait a bit to avoid need to support yet another version. I can bet every new version of HTTP will cost millions of dollars across the industry. It is not agile where you just drop in a new increment. This is the base everybody need to support then and you won't be able to stop support in foreseeable future.
- jacquesm 12y ago
  > I can bet every new version of HTTP will cost millions of dollars across the industry. That would be a fairly easy bet, but I doubt anybody would take the other side. My own estimate at rolling out a major HTTP protocol revision across the industry would be in the 100's of millions. Take into account that we have approximately 750 million web sites and 3 billion clients.

stormbrew 12y ago

I am so glad there is at least one prominent name advocating this line, because I feel like this quote from another IETF discussion is becoming more and more relevant: > Is there an IETF process in place for "The work we're doing would harm the Internet so maybe we should stop?" - http://www.ietf.org/mail-archive/web/trans/current/msg00238.html http://www.ietf.org/mail-archive/web/trans/current/msg00238.... HTTP/2.0 has been rammed through much faster than is reasonable for the next revision of the bedrock of the web. It was always clearly a single-bid tender for ideas, with the call for proposals geared towards SPDY and the timeline too short for any reasonable possibility of a competitive idea to come up. There has never been any good reason that SPDY could not co-evolve with HTTP as it had already been doing quite successfully. If it was truly the next-step it would have been clear soon enough. All jamming it through to HTTP/2.0 does is create a barrier for entry for similar co-evolved ideas to come about and compete on even footing.

youngtaff 12y ago
PHK has always been skeptical of HTTP/2 & SPDY He wants radical change in the protocol but when given the opportunity submitted a (by his own admission) half baked proposal - there's also the question of what a protocol like HTTP/2 means for his product. Although HTTP/2 started from SPDY it has evolved, and in different ways e.g. see the framing comments from the thread the OP links to. We need a better protocol for the web now, yes we could wait around longer for more discussion but where did that get us with HTTP/1.1 - I'd be quite happy if IETF had just adopted SPDY lock, stock and barrel (and no I don't work for Google)
- stormbrew 12y ago
  I'm aware that he's always been skeptical, I saw his posts as my own excitement over the idea of HTTP/2.0 died on the vine from being subscribed to the WG mailing list. There has never and will never be a point in time where we don't need "a better protocol for the web now." The issue is that canonization was unnecessary, adoption of spdy has been progressing fine without it. And HTTP/2 diverging significantly from spdy does not inspire confidence, either. Rather it just reminds of a famous xkcd [1]and again begs the question of whether trying to turn spdy into http/2 even manages to achieve any of the goals the process was setting out for. The whole thing just seems like a big fat SNAFU. [1] http://xkcd.com/927/ http://xkcd.com/927/

taspeotis 12y ago

Related [1]: Wired: How has your thinking about design changed over the past decades? Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled programmers to “throw the first version away,” then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised. [1] http://www.wired.com/2010/07/ff_fred_brooks/ http://www.wired.com/2010/07/ff_fred_brooks/

orkoden 12y ago
This is true for application software you write. Standards work differently.
bostik 12y ago
I am not sure how well that applies to a protocol that is supposed to be codified in every single browser, web server and utility library in the world. The iteration cycle will be slow, and improvements can not happen overnight. Now, if the name was something like HTTP/1.8-alpha it might be a different thing. At least then it wouldn't carry the label of the "next big thing for everyone". It's sad, but names (and branding) do matter. Forcing a known-broken implementation upon the world is not exactly good engineering.
- twic 12y ago
  WebSockets went through a series of iteration cycles like this. It wasn't entirely smooth sailing, but it seems to have worked out.
- wmf 12y ago
  Google can iterate on SPDY and QUIC by just releasing new versions of Chrome, which is where all the knowledge behind HTTP 2.0 came from.
  - dsl 12y ago
    This is often overlooked as the single biggest failing of SPDY... its a protocol designed to work well for Google, which operates completely differently from every other web property. Google in-houses everything so a single fast multiplexed connection to a single server makes sense. Every other website has external content, ads, like buttons, etc. and you end up having to spin up 30-40 independent SPDY connections, eliminating all benefit.

jballanc 12y ago

I think this (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0816.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...) follow-up makes a valid point: > In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I don’t believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody else’s problem. If we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past. That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.

pjc50 12y ago
The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.
- skrebbel 12y ago
  So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel. I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.
  - gtirloni 12y ago
    Looked like a good idea until you mentioned JavaScript. Bummer.

chacham15 12y ago

I think that one of the best things about HTTP/1.0 (and to a lesser extent 1.1) is its simplicity. The reason, to me, that that simplicity is so vital is because it has fostered large amounts of innovation.

maaaats 12y ago

What an awful way to try and get a point across. An aggressive tone and negative words baked into every other sentence, making the statements very loaded. There's probably a lot of missing context from viewing only this link, though.

lerouxb 12y ago

I think it makes sense to take the time to get it right. Every version of HTTP will effectively have to be supported by just about every server and client forever or otherwise the web will break. An incredible aspect of the web is that Tim Berners-Lee's first website back at CERN still works in modern browsers. Same with things like basically the entire Geocities archive. When it gets to core infrastructure like HTTP you can't just iterate quickly and expect the entire internet to constantly upgrade along with you. What works for early stage lean startups won't work here.

zhyder 12y ago

Interesting response from the WG chair: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0820.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... An aside: I find it odd how HN users jump to agreement when a link to a single mailing-list message is posted, ignoring other discussion on the thread. I think it's because the UI makes it hard to see the rest of the conversation (unlike -say- the comments UI on HN itself)

higherpurpose 12y ago

I'm in favor of dumping HTTP/S and using a faster and more secure (by default) Transport protocol altogether. Post Snowden revelations we should be focusing our energy on that, rather than continuing to hack around this old protocol to make it faster and more secure.

marios 12y ago
MinimaLT [1] comes to mind. Minimal latency through better security sounds very appealing, especially when it's not a marketint trick but a paper signed by people like DJB. The way I see it though, is not only to have a protocol, but how to get adoption. Especially when you're talking about network protocols, you need rock solid stacks in all major operating systems which is not an easy feat to accomplish. [1]: http://cr.yp.to/tcpip/minimalt-20130522.pdf http://cr.yp.to/tcpip/minimalt-20130522.pdf

brianpgordon 12y ago

I haven't been following the development of HTTP/2.0. What are the most egregious "warts and mistakes" in SPDY?

fredliu 12y ago
Mobile is one of them, although OP's arguments are valid as well. (http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf) Also, among many other things: every thing over SSL. Single Connection. Also, less of a technical problem, but as many already mentioned, too complicated as compared to plain text human readable HTTP 1.x
- zobzu 12y ago
  also ssl everywhere without authentication by default. ie slower, encrypted, but not actually safe.

justincormack 12y ago

There is another interesting thread about internet of things http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0602.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should not have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others." http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0604.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... "First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."

youngtaff 12y ago
Pretty sure every ecommerce site will benefit from deploying HTTP/2 (although their tendency to fill sites full of third party components may reduce some of its benefits)
- justincormack 12y ago
  Well the complexity makes it hard to build a performant server. https://groups.google.com/forum/#!searchin/mechanical-sympathy/http/mechanical-sympathy/CWyAD-oF9Uw/ycO0vxGqMvsJ https://groups.google.com/forum/#!searchin/mechanical-sympat...
- fredliu 12y ago
  Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf http://conferences.sigcomm.org/co-next/2013/program/p303.pdf <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.

sebcat 12y ago

It should be noted that the sender of this e-mail is Poul-Henning Kamp, known among other things for another e-mail from back in the day (relatively speaking): http://bikeshed.com/ http://bikeshed.com/

quasque 12y ago

Would it be accurate to suggest that the rushing of Google's SPDY, as HTTP/2.0, through IETF standardisation is roughly equivalent to the situation a few years ago when Microsoft pushed Office Open XML through as an ECMA standard? Or is that just a huge mischaracterisation?

marcosdumay 12y ago
That's a huge mischaracterization. There are a few different implementations of SPDY, and a clear use case where it applies. Also, it's a clear standard, made for being used. What's happening here is that there is a group of very active people that create most of the software we use on the web, and have a use case they want to support. At the same time, there are lots and lots of people that are not as active, with a huge amount of use cases that will be hindered, but since they are not active, they have very little voice.
- quasque 12y ago
  Thanks for the explanation, I haven't been following the progress of SPDY so I'm not familiar with the detail. What use cases would be hindered by this new standard?
  - marcosdumay 12y ago
    There are people complaining that it will break things because it's binary, that they can't have mandatory encryption, and that it's just too complex to fit in limited resources. There are probably other complaints that I didn't see. I've never read it in enough depth to verify those claims, but the response from the standard group is always "then use HTTP 1.1", what is as a non-solution as it gets. SPDY was great exactly because it was not the standard, it was an extra option, available if everybody agreed to it. Call it HTTP 2, and it will become mandatory in no time. IETF calling it optional won't change a thing.

mantrax5 12y ago

You know what we need, we need to pick one of those people and give 'em one day to invent HTTP/2.0 and it'll be a better spec compared to letting them all "decide" together by nerd-fighting each other into eternity. No standard is perfect, but the worst standard is no standard. Make up your fucking mind already.

gioele 12y ago

To put the comment and its author in context, Poul-Henning Kamp is the main developer of Varnish, a widely used high-performance standard-compliant HTTP cache. PHK has experience of HTTP both from the server point of view (the main job of Varnish is acting as a fast HTTP server) and from client point of view (Varnish acts as client to the slow upstream HTTP servers). As a side note, he also refrained for years from adding TLS support to Varnish after his review of OpenSSL and SSL in general (see https://www.varnish-cache.org/docs/trunk/phk/ssl.html https://www.varnish-cache.org/docs/trunk/phk/ssl.html ).

ruben_varnish 12y ago
Good one. More context on the ideas and proposal Poul-Henning has put on the table: http://phk.freebsd.dk/words/httpbis.html http://phk.freebsd.dk/words/httpbis.html

cwp 12y ago

Sounds to me like the real problem is lack of IP addresses, and the best strategy would be to hold off on updating HTTP and work on IPv6 ubiquity first. I can see why Google went a different route, but we don't all have to follow.

phkamp 12y ago

I'm here in case you want to ask me anything. Poul-Henning

acdha 12y ago
For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over. http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0833.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.
- phkamp 12y ago
  I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason. If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP. Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause. And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol. Nobody seems to have heard the expression "Festina Lente" in this WG.
  - throwaway7767 12y ago
    If I understand your argument correctly, you are opposed to oppurtunistic encryption as there is no identity validation, as it does not improve privacy. But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that? (I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)

themgt 12y ago

A much better comment to link to would have the grandparent, by Greg Wilkins from Jetty, who gives a lot more substance and context to the debate: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0807.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... It does seem a little shocking that the WG chair is proposing last call while still there's serious discussion of things like dropping HPACK.

josteink 12y ago

Just like they admitted that XHTML 2 was a mistake and scraped it, I feel they should do the same with this nonsense. Nothing about spdy or http2.0 sparks any sort of confidence with regard to proper robust protocol design, keeping things simple nor properly separating concerns.

haberman 12y ago
It's funny that you mention XHTML 2, because I think it demonstrates the opposite of what you are arguing. XHTML 2 is a lot more like what PHK is proposing: an attempt to "rethink" HTML, come up with something simpler, revolutionary rather than evolutionary, "The Right Thing." It was an attempt to reinvent the space from first principles, and had lots of ideas that were theoretically good but unproven at large scale. When that went nowhere, the world settled on HTML5: evolutionary, incremental, and based on standardizing existing practice. Much less sexy, but more useful in practice. There is a time and a place for bold new ideas, but a standards body designing v2 of a protocol isn't it. Standards are for codifying proven ideas. When standards bodies try to innovate you end up with XHTML, VRML, P3P, SPARQL, etc.
dragonwriter 12y ago
> Just like they admitted that XHTML 2 was a mistake and scraped it But "they" (the W3C) didn't do that when people were just complaining about issues with the XHTML 2.0 approach, they did it after a competing approach was developed via an extensive, multi-year process through an outside group (WHATWG), and even then only that after a short period when both approaches were the focus of official W3C working groups. They didn't adopt a "this is limited, lets throw it away and start over" approach as the original article here calls for with regard to HTTP/2.0.

alexnewman 12y ago

It's not perfect so start over. Seems like the definition of why v2 is always so hard.