3 ms·

I just feel like the basic idea of HTTP 2.0 misses the point of a stateless, text-based protocol. Also, muxing, flowcontrol? These are not things application

I just feel like the basic idea of HTTP 2.0 misses the point of a stateless, text-based protocol. Also, muxing, flowcontrol? These are not things application level protocols should be caring about.

shawnz 13y ago
HTTP 2.0 is a bet that those ideals don't matter anymore. If the users of HTTP disagree, it just won't be adopted, simple as that.
- srd 13y ago
  Until bosses without a low-level IT background show up and ask you why you're not expanding their buzzword bingo options.
angersock 13y ago
One wonders why the hell they're trying to fix flow-control, traffic priority, encryption, etc. in a standard meant for just moving around document. It reeks of overengineering--might as well spend that energy improving TCP or putting together a better secure sockets layer. Most of the problems they cite are the result of people shoving too much shit (ads, trackers, social media, etc.) into their sites anyways.
- FooBarWidget 13y ago
  It reeks of overengineering because you're not properly understanding the problem. Flow control is necessary because it's a multiplexed protocol. Without your own flow control commands, flow control is applied over the entire TCP stream, not on your substreams. That doesn't do what you want. Try it: implement any kind of multiplexed protocol yourself, and you will quickly see why it is necessary. Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session. Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly.
  - jimktrains2 13y ago
    > Flow control is necessary because it's a multiplexed protocol. Without your own flow control commands, flow control is applied over the entire TCP stream, not on your substreams. That doesn't do what you want. Try it: implement any kind of multiplexed protocol yourself, and you will quickly see why it is necessary. Why should HTTP be a multiplex protocol though; that's the issue. > Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session. So why not just use SSL/TLS? Why wrap it into the HTTP protocol? > Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly. Those who can't see the benefits and reason for HTTP1 are doomed to make a mess of it by "improving" (or "working around") it.
    - FooBarWidget 13y ago
      > Why should HTTP be a multiplex protocol though; that's the issue. Because HTTP is inefficient due to the TCP three-way handshake, and because pipelining has many problems. These are fixed by multiplexing. > So why not just use SSL/TLS? Why wrap it into the HTTP protocol? They are using TLS.
      - jimktrains2 13y ago
        > Because HTTP is inefficient due to the TCP three-way handshake, and because pipelining has many problems. These are fixed by multiplexing. So why should HTTP care about this? > They are using TLS. But it's specified as part of the HTTP protocol
X-Cubed 13y ago
It does miss the point of a stateless, text-based protocol but only because that's core to the problems currently experienced in HTTP/1.1 that are identified near the start of the presentation. The nice thing about this approach is that it is entirely contained such that the web application in the browser doesn't know (or even need to know) the difference, in the same way that current web applications don't need to worry about whether the request data was compressed or not.
- comex 13y ago
  Certainly, there are plenty of things in HTTP 2.0 that make sense to be there, such as server push, specialized header compression, etc. However, some things, such as avoiding making multiple connections due to congestion and due to slow-start being slow, flow control, and arguably encryption, seem like they would be better addressed in TCP. And in fact, Google is trying to do that with QUIC. The problem is that if (when) those things get standardized in HTTP/2.0, they need to be supported forever, even if an improved transport layer protocol makes them obsolete in relatively short order.
  - jimktrains2 13y ago
    Your post made me reflect a bit and I agree with you whole-heartedly. I wouldn't have such a visceral dislike of HTTP/2.0 if it didn't have the TCP-like features in it.
  - FooBarWidget 13y ago
    You can't address things in TCP. There is so much network infrastructure deployed that trying to push any non-backward compatible change in TCP is futile. Google did the right thing by addressing the problems in layer 5.
    - comex 13y ago
      Then just tunnel on top of UDP, like QUIC currently does. Doesn't mean it has to be specific to one application.
zobzu 13y ago
it fixes what google cares about

I just feel like the basic idea of HTTP 2.0 misses the point of a stateless, text-based protocol. Also, muxing, flowcontrol? These are not things application level protocols should be caring about.

shawnz 13y ago

HTTP 2.0 is a bet that those ideals don't matter anymore. If the users of HTTP disagree, it just won't be adopted, simple as that.

srd 13y ago
Until bosses without a low-level IT background show up and ask you why you're not expanding their buzzword bingo options.

angersock 13y ago

One wonders why the hell they're trying to fix flow-control, traffic priority, encryption, etc. in a standard meant for just moving around document. It reeks of overengineering--might as well spend that energy improving TCP or putting together a better secure sockets layer. Most of the problems they cite are the result of people shoving too much shit (ads, trackers, social media, etc.) into their sites anyways.

FooBarWidget 13y ago
It reeks of overengineering because you're not properly understanding the problem. Flow control is necessary because it's a multiplexed protocol. Without your own flow control commands, flow control is applied over the entire TCP stream, not on your substreams. That doesn't do what you want. Try it: implement any kind of multiplexed protocol yourself, and you will quickly see why it is necessary. Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session. Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly.
- jimktrains2 13y ago
  > Flow control is necessary because it's a multiplexed protocol. Without your own flow control commands, flow control is applied over the entire TCP stream, not on your substreams. That doesn't do what you want. Try it: implement any kind of multiplexed protocol yourself, and you will quickly see why it is necessary. Why should HTTP be a multiplex protocol though; that's the issue. > Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session. So why not just use SSL/TLS? Why wrap it into the HTTP protocol? > Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly. Those who can't see the benefits and reason for HTTP1 are doomed to make a mess of it by "improving" (or "working around") it.
  - FooBarWidget 13y ago
    > Why should HTTP be a multiplex protocol though; that's the issue. Because HTTP is inefficient due to the TCP three-way handshake, and because pipelining has many problems. These are fixed by multiplexing. > So why not just use SSL/TLS? Why wrap it into the HTTP protocol? They are using TLS.
    - jimktrains2 13y ago
      > Because HTTP is inefficient due to the TCP three-way handshake, and because pipelining has many problems. These are fixed by multiplexing. So why should HTTP care about this? > They are using TLS. But it's specified as part of the HTTP protocol

X-Cubed 13y ago

It does miss the point of a stateless, text-based protocol but only because that's core to the problems currently experienced in HTTP/1.1 that are identified near the start of the presentation. The nice thing about this approach is that it is entirely contained such that the web application in the browser doesn't know (or even need to know) the difference, in the same way that current web applications don't need to worry about whether the request data was compressed or not.

comex 13y ago
Certainly, there are plenty of things in HTTP 2.0 that make sense to be there, such as server push, specialized header compression, etc. However, some things, such as avoiding making multiple connections due to congestion and due to slow-start being slow, flow control, and arguably encryption, seem like they would be better addressed in TCP. And in fact, Google is trying to do that with QUIC. The problem is that if (when) those things get standardized in HTTP/2.0, they need to be supported forever, even if an improved transport layer protocol makes them obsolete in relatively short order.
- jimktrains2 13y ago
  Your post made me reflect a bit and I agree with you whole-heartedly. I wouldn't have such a visceral dislike of HTTP/2.0 if it didn't have the TCP-like features in it.
- FooBarWidget 13y ago
  You can't address things in TCP. There is so much network infrastructure deployed that trying to push any non-backward compatible change in TCP is futile. Google did the right thing by addressing the problems in layer 5.
  - comex 13y ago
    Then just tunnel on top of UDP, like QUIC currently does. Doesn't mean it has to be specific to one application.

zobzu 13y ago

it fixes what google cares about