4 ms·

We've decided that HTTP/2 may not be a great fit at its present state, and here's why we thought so: http://blog.geog.co/post/111535045146/our-thoughts-on-http

by guilt 12y ago

We've decided that HTTP/2 may not be a great fit at its present state, and here's why we thought so: http://blog.geog.co/post/111535045146/our-thoughts-on-http2 http://blog.geog.co/post/111535045146/our-thoughts-on-http2 Also, is that article from the Author of cURL? We <3 cURL!

AlyssaRowan 12y ago
No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster. If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.
- guilt 12y ago
  If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
  - 001spartan 12y ago
    I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
    - AlyssaRowan 12y ago
      A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
      - guilt 12y ago
        For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
  - teraflop 12y ago
    If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.
bagder 12y ago
Yes it is indeed by the author of curl! (me ;-)
- guilt 12y ago
  It's been an honour meeting you here! Thank you for cURL! :)
acdha 12y ago
The bit about HTTP 1 is only true without TLS: https://http2.github.io/faq/#can-i-implement-http2-without-implementing-http11 https://http2.github.io/faq/#can-i-implement-http2-without-i... This bit is also mostly wrong: “However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.” That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services. That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.
- guilt 12y ago
  Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling! I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
  - acdha 12y ago
    Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.

by guilt 12y ago

AlyssaRowan 12y ago

No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster. If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.

guilt 12y ago
If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
- 001spartan 12y ago
  I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
  - AlyssaRowan 12y ago
    A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
    - guilt 12y ago
      For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
- teraflop 12y ago
  If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.

bagder 12y ago

Yes it is indeed by the author of curl! (me ;-)

guilt 12y ago
It's been an honour meeting you here! Thank you for cURL! :)

acdha 12y ago

The bit about HTTP 1 is only true without TLS: https://http2.github.io/faq/#can-i-implement-http2-without-implementing-http11 https://http2.github.io/faq/#can-i-implement-http2-without-i... This bit is also mostly wrong: “However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.” That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services. That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.

guilt 12y ago
Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling! I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
- acdha 12y ago
  Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.