10 ms·

Hypertext Transfer Protocol Version 2

99 points by yoavz 12y ago

wmf 12y ago
For context, this is the really-almost-final draft of HTTP/2. I would say speak now or forever hold your peace, but it's even too late for that.
bkeroack 12y ago
So TLS still isn't mandatory? Seems like a missed opportunity.
- Mandatum 12y ago
  I agree encryption is something that should be mandatory, but you can't pin down an encryption algo to be used by HTTP/2 without allowing for future changes..
  - XorNot 12y ago
    I think you should always be able to turn encryption off. Encryption is expensive. I run OpenSSH-HPN partly so, on my local network I can get secure logins but then not pay the throughput hit of encryption when it just doesn't matter. The same even applies to internet connections, such as big but generally uninteresting things like log files. Defaulting to "encryption enabled" and throwing a browser warning of "encryption disabled" makes perfect sense, but you definitely should be able to turn it off for content where it doesn't matter.
    - deleted 12y ago
      [deleted]
    - AlyssaRowan 12y ago
      Ah, you think your local network is trusted? So did Google. It isn't.
      - XorNot 12y ago
        I'm impressed I'm somehow getting modded down for that opinion. My local network is trusted. Google does not have a local network. But the cables and wires physically within my house or even my office building can be presumed to be secure, since if you can get access to those, then you could also just take the physical machines by any numbers of methods. You also don't address "large but insensitive data" - which is where YouTube video downloads and the like mostly lies. Encryption is not costless on small devices like laptops/desktops.
        AlyssaRowan 12y ago
        Considering that your local network is trusted defies "defense in depth" - do you use Telnet for your admin? What happens with your Wifi, or if one of your computers gets pwned and starts becoming a packet-sniffing machine? Google feel it's potentially sensitive data. After all, it's showing what you're reading, what you're downloading, what you're seeing. Laptops/desktops are way too big to feel any noticeable effect from modern encryption: that's nonsense, look at the benches. You won't even feel that impact on a Raspberry Pi (actually the VC4 is surprisingly good at some crypto - I'm halfway to a ChaCha implementation on it, if I can just sort out the diagonal round permutation!). TLS 1.2+extensions and 1.3 will have things which make good encryption even faster: the use of fast AEADs like AES-GCM and ChaCha20-Poly1305, and ECDHE using Curve25519, etc. This decision is underpinned by, and supported by, all that work. If your use case was toasters and 8-bit microcontrollers (as opposed to 16-bit or 32-bit AVR-type ones), then you'd have a discussion, but I've seen efficient Atmega implementations of this, I could probably cook something up for a 68000 myself, and anyone who really fancies a challenge should go for a 6502 or z80 implementation. I'd simply respond that lack of privacy is not costless, and you've really no excuse anymore.
        XorNot 12y ago
        Try using SSH for big file transfers. Oh right - you don't - because the throughput is CPU limited by the encryption. Multithread it? Sure, now watch as your 8 core machine peaks pushing a gigabit of encrypted data which is actually just an image file of a movie you already have. You encrypt credentials (because they grant access) and sensitive data - like bank details. You don't encrypt the legal rips of movies you have streaming over your network because hey, that would be a complete waste of energy and processing power for literally zero-benefit. Always on encryption is pointless and the type of always on encryption with HTTP 2 people talk about is worse then pointless. The idea that MitM is difficult is a farce - any number of WPS hijacking techniques involve forcing the host offline temporarily so it has to re-authenticate. The same thing would apply here. Taking what, 2 seconds? You talk about defense in depth - one aspect of that is that a leaking side-channel has finite bandwidth and can't possibly hope to capture "all the data" which means it has to try and capture important data.
- konklone 12y ago
  Mark Nottingham, who's chairing the working group, and has been at this stuff for a while, has a blog post about this: https://www.mnot.net/blog/2014/01/04/strengthening_http_a_personal_view https://www.mnot.net/blog/2014/01/04/strengthening_http_a_pe... Chrome and Firefox will still insist on TLS for HTTP/2. In addition, the HTTP/2 spec does mandate that any implementation must support TLS 1.2 and up, and it must support forward secret ciphersuites. http://http2.github.io/http2-spec/#TLSUsage http://http2.github.io/http2-spec/#TLSUsage
- plaguuuuuu 12y ago
  what if you want to roll your own encryption layer?
- AlyssaRowan 12y ago
  That's something the browsers are going to deal with. Chrome and Firefox have explicitly said they'll require HTTP/2 over TLS, full-stop. The big pushbacks came mostly from middlebox-makers, proxies and the like. Unsurprising. The market will decide. I'm sure the remaining browsers will make their own decisions, and I expect Opera and IE to fall on the TLS side, and then the decision will be effectively made. The TLS WG will watch the result with interest, I'm sure, looking forward into TLS 1.4/2.0/whatever...
  - M2Ys4U 12y ago
    IIRC, Microsoft has already stated that IE will support unencrypted HTTP/2.
    - AlyssaRowan 12y ago
      That's "under review"...
diafygi 12y ago
There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.
- api 12y ago
  At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.
  - bkeroack 12y ago
    STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP. Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".
    - 0x0 12y ago
      Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...
      - XorNot 12y ago
        The problem is browsers are mostly lousy at giving a good user experience with self-signed certificates. 99% of the time, self-signed doesn't matter except if the certificate changes unexpectedly - i.e. the service just isn't that important. The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means. Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.
stonogo 12y ago
The best description of this protocol I have seen is "TCP over TCP."
- johnrob 12y ago
  I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).
  - stonogo 12y ago
    I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.
    - api 12y ago
      The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc. Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers. So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat. SSH is another penultimate tcp over tcp protocol. The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.
      - xorcist 12y ago
        The firewalls are going to get very expensive once everything runs on port 80. Unhappy users are sometimes the only way to get policies to change.
wyager 12y ago
To those saying HTTP2 should require HTTPS: do you really want to be stuck with our shitty CA model for even longer?
- diafygi 12y ago
  Alternative? Non-https is really harmful to users who browse via open wifi.
  - wyager 12y ago
    >Alternative? There exist several semi-viable alternatives at the moment. The most promising is Namecoin, which essentially allows for cryptographically authenticated public key/value storage, and so can function as both a DNS system and a system for announcing SSL pubkeys (without any trusted parties).
    - pg_is_a_butt 12y ago
      trusting namecoin implementation doesn't count?
  - stephenr 12y ago
    can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.
    - harshreality 12y ago
      Let's assume a simple video site and html5 video. Do you want to bet there are no vulnerabilities in your browser's mp4/vp8 decoder? If there are, anyone can MITM your non-SSL connection and compromise the video decoding process, limited only by their cleverness and by whatever sandboxing your browser employs.
      - stephenr 12y ago
        Why does it have to be video? Some of the simplest sites around are plain text or text and images. Why do I need SSL or TLS to view either of these? I am very aware that anything authenticated should be carried over an encrypted connection - I'm not arguing against that. I'm saying there are use-cases that do not require it.
0x0 12y ago
I'm curious to see how transparent proxies handle all the crazy framing (will poor software corrupt the bytestream?) and if there will be a wave of exploits for both client and server implementations; the complexity and subtleties appear to be almost a magnitude higher than http/1.
- lazyloop 12y ago
  That's simple, they just won't, browsers will only support HTTP/2 over TLS, so proxies are effectively dead.
  - xorcist 12y ago
    Every large web site uses a load balancer, effectively a proxy. I don't understand why Poul Henning-Kamp's experience with that didn't carry more weight in the working group.
    - wmf 12y ago
      In HTTP terms a reverse proxy is just a Web server (what it does internally is its own business), not a proxy. HTTP/2 load balancers have no trouble terminating TLS.
      - xorcist 12y ago
        If you disagree with PHK, you have to refute the details in his notes, not just wave them away. That they can be made to work does not mean there is not a problem.
        wmf 12y ago
        PHK keeps calling for radical changes to HTTP semantics which other people don't have the stomach for and would take a decade to deploy even if they did. In some sense, getting HTTP/2 done quickly clears the field for people like PHK to start on HTTP/3 sooner.
nly 12y ago
The accompanying HTTP header compression standard seems a lot more terrifying on the complexity scale, compared to Googles suggestion with SPDY of just dumping everything through zlib: http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09 http://tools.ietf.org/html/draft-ietf-httpbis-header-compres...
- agl 12y ago
  But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME http://en.wikipedia.org/wiki/CRIME. I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data and compress them separately while still being wire compatible with zlib. I'll be very happy when I can remove it.
  - girvo 12y ago
    I was going through that article after you posted it... is BREACH still an exploit in the wild? Turning off compression altogether seems painful :/
    - AlyssaRowan 12y ago
      Well, the exploit doesn't just go away. Any context compressor could introduce the same hole if attacker-provided and sensitive data share contexts. Specific countermeasures include salting your anti-CSRF tokens (so make sure they're not consistent but differ on every page load!).
  - bsdetector 12y ago
    Just like it turned out that minimized HTTP was faster than SPDY: http://research.microsoft.com/apps/pubs/?id=170059 http://research.microsoft.com/apps/pubs/?id=170059 I'm not sure what the motivation is behind HTTP2/SPDY. There have been consistent misinformation from Google about the performance of it (for instance including initial connection time for HTTP but omitting it for SPDY, using an outdated HTTP stack, not using HTTP pipelining) so I doubt the motivation is performance. It looks like just not-invented-here bloat, but I wouldn't be surprised to find out that the SPDY connection to google-analytics.com is kept open and reused across tabs.
ChikkaChiChi 12y ago
Is there any particular reason why more work isn't being done on developing new protocols? It seems like given the past 20 years of the web there is clearly a need of a presentation protocol, a stateful application protocol, and a stateless application protocol. Seems like it makes more sense to separate them.
- michaelsbradley 12y ago
  OPC UA is a relatively new standard worth a look for those in the market for a stateful application protocol that provides both an information model and transport layer. One downside is that, presently, only member organizations of the OPC Foundation are given full access to the specifications and reference implementations. Membership is certainly affordable, but interest and adoption might be accelerated if the specs and reference clients/servers were publicly accessible. Perhaps if the Foundation received enough enthusiastic inquiries they might change their policy in that regard. http://en.wikipedia.org/wiki/OPC_Unified_Architecture http://en.wikipedia.org/wiki/OPC_Unified_Architecture https://opcfoundation.org/about/opc-technologies/opc-ua/ https://opcfoundation.org/about/opc-technologies/opc-ua/
ksec 12y ago
So what exactly is from HTTP2 to SPDY except for the TLS encryption?
BorisMelnik 12y ago
Anyone have a link to a overview type blog post of the changes? This is a tad foreign for a guy like me who has little experience of this layer of the OSI model.
- wmf 12y ago
  http://queue.acm.org/detail.cfm?id=2555617 http://queue.acm.org/detail.cfm?id=2555617 https://www.mnot.net/blog/2014/01/30/http2_expectations https://www.mnot.net/blog/2014/01/30/http2_expectations https://www.mnot.net/talks/http2-wtf/#/ https://www.mnot.net/talks/http2-wtf/#/
  - BorisMelnik 12y ago
    very cool, thank you wmf that first one did the trick! I really can't beleive how hacked together / behind the original specification is compared to 2.
kevinpaladin 12y ago
"Expires: January 31, 2015" - What does it mean?
- wmf 12y ago
  All Internet-drafts "expire" because they're intended to be work-in-progress documents that should either be updated to a new draft, finalized into an RFC, or abandoned. In this case, HTTP/2 will become an RFC long before January.

99 points by yoavz 12y ago

wmf 12y ago

For context, this is the really-almost-final draft of HTTP/2. I would say speak now or forever hold your peace, but it's even too late for that.

bkeroack 12y ago

So TLS still isn't mandatory? Seems like a missed opportunity.

Mandatum 12y ago
I agree encryption is something that should be mandatory, but you can't pin down an encryption algo to be used by HTTP/2 without allowing for future changes..
- XorNot 12y ago
  I think you should always be able to turn encryption off. Encryption is expensive. I run OpenSSH-HPN partly so, on my local network I can get secure logins but then not pay the throughput hit of encryption when it just doesn't matter. The same even applies to internet connections, such as big but generally uninteresting things like log files. Defaulting to "encryption enabled" and throwing a browser warning of "encryption disabled" makes perfect sense, but you definitely should be able to turn it off for content where it doesn't matter.
  - deleted 12y ago
    [deleted]
  - AlyssaRowan 12y ago
    Ah, you think your local network is trusted? So did Google. It isn't.
    - XorNot 12y ago
      I'm impressed I'm somehow getting modded down for that opinion. My local network is trusted. Google does not have a local network. But the cables and wires physically within my house or even my office building can be presumed to be secure, since if you can get access to those, then you could also just take the physical machines by any numbers of methods. You also don't address "large but insensitive data" - which is where YouTube video downloads and the like mostly lies. Encryption is not costless on small devices like laptops/desktops.
      - AlyssaRowan 12y ago
        Considering that your local network is trusted defies "defense in depth" - do you use Telnet for your admin? What happens with your Wifi, or if one of your computers gets pwned and starts becoming a packet-sniffing machine? Google feel it's potentially sensitive data. After all, it's showing what you're reading, what you're downloading, what you're seeing. Laptops/desktops are way too big to feel any noticeable effect from modern encryption: that's nonsense, look at the benches. You won't even feel that impact on a Raspberry Pi (actually the VC4 is surprisingly good at some crypto - I'm halfway to a ChaCha implementation on it, if I can just sort out the diagonal round permutation!). TLS 1.2+extensions and 1.3 will have things which make good encryption even faster: the use of fast AEADs like AES-GCM and ChaCha20-Poly1305, and ECDHE using Curve25519, etc. This decision is underpinned by, and supported by, all that work. If your use case was toasters and 8-bit microcontrollers (as opposed to 16-bit or 32-bit AVR-type ones), then you'd have a discussion, but I've seen efficient Atmega implementations of this, I could probably cook something up for a 68000 myself, and anyone who really fancies a challenge should go for a 6502 or z80 implementation. I'd simply respond that lack of privacy is not costless, and you've really no excuse anymore.
        XorNot 12y ago
        Try using SSH for big file transfers. Oh right - you don't - because the throughput is CPU limited by the encryption. Multithread it? Sure, now watch as your 8 core machine peaks pushing a gigabit of encrypted data which is actually just an image file of a movie you already have. You encrypt credentials (because they grant access) and sensitive data - like bank details. You don't encrypt the legal rips of movies you have streaming over your network because hey, that would be a complete waste of energy and processing power for literally zero-benefit. Always on encryption is pointless and the type of always on encryption with HTTP 2 people talk about is worse then pointless. The idea that MitM is difficult is a farce - any number of WPS hijacking techniques involve forcing the host offline temporarily so it has to re-authenticate. The same thing would apply here. Taking what, 2 seconds? You talk about defense in depth - one aspect of that is that a leaking side-channel has finite bandwidth and can't possibly hope to capture "all the data" which means it has to try and capture important data.
konklone 12y ago
Mark Nottingham, who's chairing the working group, and has been at this stuff for a while, has a blog post about this: https://www.mnot.net/blog/2014/01/04/strengthening_http_a_personal_view https://www.mnot.net/blog/2014/01/04/strengthening_http_a_pe... Chrome and Firefox will still insist on TLS for HTTP/2. In addition, the HTTP/2 spec does mandate that any implementation must support TLS 1.2 and up, and it must support forward secret ciphersuites. http://http2.github.io/http2-spec/#TLSUsage http://http2.github.io/http2-spec/#TLSUsage
plaguuuuuu 12y ago
what if you want to roll your own encryption layer?
AlyssaRowan 12y ago
That's something the browsers are going to deal with. Chrome and Firefox have explicitly said they'll require HTTP/2 over TLS, full-stop. The big pushbacks came mostly from middlebox-makers, proxies and the like. Unsurprising. The market will decide. I'm sure the remaining browsers will make their own decisions, and I expect Opera and IE to fall on the TLS side, and then the decision will be effectively made. The TLS WG will watch the result with interest, I'm sure, looking forward into TLS 1.4/2.0/whatever...
- M2Ys4U 12y ago
  IIRC, Microsoft has already stated that IE will support unencrypted HTTP/2.
  - AlyssaRowan 12y ago
    That's "under review"...

diafygi 12y ago

There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.

api 12y ago
At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.
- bkeroack 12y ago
  STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP. Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".
  - 0x0 12y ago
    Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...
    - XorNot 12y ago
      The problem is browsers are mostly lousy at giving a good user experience with self-signed certificates. 99% of the time, self-signed doesn't matter except if the certificate changes unexpectedly - i.e. the service just isn't that important. The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means. Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.

stonogo 12y ago

The best description of this protocol I have seen is "TCP over TCP."

johnrob 12y ago
I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).
- stonogo 12y ago
  I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.
  - api 12y ago
    The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc. Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers. So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat. SSH is another penultimate tcp over tcp protocol. The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.
    - xorcist 12y ago
      The firewalls are going to get very expensive once everything runs on port 80. Unhappy users are sometimes the only way to get policies to change.

wyager 12y ago

To those saying HTTP2 should require HTTPS: do you really want to be stuck with our shitty CA model for even longer?

diafygi 12y ago
Alternative? Non-https is really harmful to users who browse via open wifi.
- wyager 12y ago
  >Alternative? There exist several semi-viable alternatives at the moment. The most promising is Namecoin, which essentially allows for cryptographically authenticated public key/value storage, and so can function as both a DNS system and a system for announcing SSL pubkeys (without any trusted parties).
  - pg_is_a_butt 12y ago
    trusting namecoin implementation doesn't count?
- stephenr 12y ago
  can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.
  - harshreality 12y ago
    Let's assume a simple video site and html5 video. Do you want to bet there are no vulnerabilities in your browser's mp4/vp8 decoder? If there are, anyone can MITM your non-SSL connection and compromise the video decoding process, limited only by their cleverness and by whatever sandboxing your browser employs.
    - stephenr 12y ago
      Why does it have to be video? Some of the simplest sites around are plain text or text and images. Why do I need SSL or TLS to view either of these? I am very aware that anything authenticated should be carried over an encrypted connection - I'm not arguing against that. I'm saying there are use-cases that do not require it.

0x0 12y ago

I'm curious to see how transparent proxies handle all the crazy framing (will poor software corrupt the bytestream?) and if there will be a wave of exploits for both client and server implementations; the complexity and subtleties appear to be almost a magnitude higher than http/1.

lazyloop 12y ago
That's simple, they just won't, browsers will only support HTTP/2 over TLS, so proxies are effectively dead.
- xorcist 12y ago
  Every large web site uses a load balancer, effectively a proxy. I don't understand why Poul Henning-Kamp's experience with that didn't carry more weight in the working group.
  - wmf 12y ago
    In HTTP terms a reverse proxy is just a Web server (what it does internally is its own business), not a proxy. HTTP/2 load balancers have no trouble terminating TLS.
    - xorcist 12y ago
      If you disagree with PHK, you have to refute the details in his notes, not just wave them away. That they can be made to work does not mean there is not a problem.
      - wmf 12y ago
        PHK keeps calling for radical changes to HTTP semantics which other people don't have the stomach for and would take a decade to deploy even if they did. In some sense, getting HTTP/2 done quickly clears the field for people like PHK to start on HTTP/3 sooner.

nly 12y ago

The accompanying HTTP header compression standard seems a lot more terrifying on the complexity scale, compared to Googles suggestion with SPDY of just dumping everything through zlib: http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09 http://tools.ietf.org/html/draft-ietf-httpbis-header-compres...

agl 12y ago
But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME http://en.wikipedia.org/wiki/CRIME. I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data and compress them separately while still being wire compatible with zlib. I'll be very happy when I can remove it.
- girvo 12y ago
  I was going through that article after you posted it... is BREACH still an exploit in the wild? Turning off compression altogether seems painful :/
  - AlyssaRowan 12y ago
    Well, the exploit doesn't just go away. Any context compressor could introduce the same hole if attacker-provided and sensitive data share contexts. Specific countermeasures include salting your anti-CSRF tokens (so make sure they're not consistent but differ on every page load!).
- bsdetector 12y ago
  Just like it turned out that minimized HTTP was faster than SPDY: http://research.microsoft.com/apps/pubs/?id=170059 http://research.microsoft.com/apps/pubs/?id=170059 I'm not sure what the motivation is behind HTTP2/SPDY. There have been consistent misinformation from Google about the performance of it (for instance including initial connection time for HTTP but omitting it for SPDY, using an outdated HTTP stack, not using HTTP pipelining) so I doubt the motivation is performance. It looks like just not-invented-here bloat, but I wouldn't be surprised to find out that the SPDY connection to google-analytics.com is kept open and reused across tabs.

ChikkaChiChi 12y ago

Is there any particular reason why more work isn't being done on developing new protocols? It seems like given the past 20 years of the web there is clearly a need of a presentation protocol, a stateful application protocol, and a stateless application protocol. Seems like it makes more sense to separate them.

michaelsbradley 12y ago
OPC UA is a relatively new standard worth a look for those in the market for a stateful application protocol that provides both an information model and transport layer. One downside is that, presently, only member organizations of the OPC Foundation are given full access to the specifications and reference implementations. Membership is certainly affordable, but interest and adoption might be accelerated if the specs and reference clients/servers were publicly accessible. Perhaps if the Foundation received enough enthusiastic inquiries they might change their policy in that regard. http://en.wikipedia.org/wiki/OPC_Unified_Architecture http://en.wikipedia.org/wiki/OPC_Unified_Architecture https://opcfoundation.org/about/opc-technologies/opc-ua/ https://opcfoundation.org/about/opc-technologies/opc-ua/

ksec 12y ago

So what exactly is from HTTP2 to SPDY except for the TLS encryption?

BorisMelnik 12y ago

Anyone have a link to a overview type blog post of the changes? This is a tad foreign for a guy like me who has little experience of this layer of the OSI model.

wmf 12y ago
http://queue.acm.org/detail.cfm?id=2555617 http://queue.acm.org/detail.cfm?id=2555617 https://www.mnot.net/blog/2014/01/30/http2_expectations https://www.mnot.net/blog/2014/01/30/http2_expectations https://www.mnot.net/talks/http2-wtf/#/ https://www.mnot.net/talks/http2-wtf/#/
- BorisMelnik 12y ago
  very cool, thank you wmf that first one did the trick! I really can't beleive how hacked together / behind the original specification is compared to 2.

kevinpaladin 12y ago

"Expires: January 31, 2015" - What does it mean?

wmf 12y ago
All Internet-drafts "expire" because they're intended to be work-in-progress documents that should either be updated to a new draft, finalized into an RFC, or abandoned. In this case, HTTP/2 will become an RFC long before January.