3 ms·

By failed I mean h2 did not fulfill its design goal and technical potential. Most sites use h2 by just wrapping http/1.0 behind some h2-enabled CDN or upgrade

by est 8y ago

By failed I mean h2 did not fulfill its design goal and technical potential. Most sites use h2 by just wrapping http/1.0 behind some h2-enabled CDN or upgrade to latest nginx and call it done. What about h2 push? Priority? WS inside h2? Nope. No one use them obviously. I mean gRPC utilized more h2 features than most h2 browsers/CDN do.

bcherny 8y ago
I mean, it’s just the beginning right? You’re making it sound like it’s the end of the road for HTTP2.
francislavoie 8y ago
I used push with the help of Caddy. Pretty easy. I'm curious to hear what you mean by WS inside h2, not sure how that's different. WS is only http for the first part i.e. the upgrade request.
provolone 8y ago
Jetty/CometD has decent support. You can use HTTP2 as a transport for push notifications. You can also specify additional resources like scripts, css, or images to be sent on the first request. I am less worried about what most sites do and more interested in the features offered by implementations. A huge number of sites don't even use https.
- est 8y ago
  The idea is good, but static assets and dynamic content (APIs, pages, etc) have different scaling models. I don't think mix them in a single transport layer have much real world usage.
klodolph 8y ago
That doesn't sound like failure to me. Newer generations of standards and protocols have features that won't be used by everyone. The goal is not maximum feature adoption, the goal is to reduce latency. There's a tradeoff between implementation complexity and benefit that changes as you incorporate additional h2 features into your web site. At some point you decide the additional features do not provide enough benefit to support the additional implementation complexity. This is normal and expected, and I'm surprised that someone would interpret this as a failure of h2. Again, the goal of h2 is not to maximize usage of features in the h2 protocol. So judging h2 by that metric does not make any sense. I could just as easily complain that HTTP is a failure because few sites use more than just GET/POST, or because many of the headers defined in the HTTP standard are not commonly used.

by est 8y ago

bcherny 8y ago

I mean, it’s just the beginning right? You’re making it sound like it’s the end of the road for HTTP2.

francislavoie 8y ago

I used push with the help of Caddy. Pretty easy. I'm curious to hear what you mean by WS inside h2, not sure how that's different. WS is only http for the first part i.e. the upgrade request.

provolone 8y ago

Jetty/CometD has decent support. You can use HTTP2 as a transport for push notifications. You can also specify additional resources like scripts, css, or images to be sent on the first request. I am less worried about what most sites do and more interested in the features offered by implementations. A huge number of sites don't even use https.

est 8y ago
The idea is good, but static assets and dynamic content (APIs, pages, etc) have different scaling models. I don't think mix them in a single transport layer have much real world usage.

klodolph 8y ago

That doesn't sound like failure to me. Newer generations of standards and protocols have features that won't be used by everyone. The goal is not maximum feature adoption, the goal is to reduce latency. There's a tradeoff between implementation complexity and benefit that changes as you incorporate additional h2 features into your web site. At some point you decide the additional features do not provide enough benefit to support the additional implementation complexity. This is normal and expected, and I'm surprised that someone would interpret this as a failure of h2. Again, the goal of h2 is not to maximize usage of features in the h2 protocol. So judging h2 by that metric does not make any sense. I could just as easily complain that HTTP is a failure because few sites use more than just GET/POST, or because many of the headers defined in the HTTP standard are not commonly used.