4 ms·

I almost didn't reply because it sounds like you have a bit of an axe to grind against HTTP/2, but the concerns you state are overblown. All I really gathered f

I almost didn't reply because it sounds like you have a bit of an axe to grind against HTTP/2, but the concerns you state are overblown. All I really gathered from the presentation was that spriting and concatenation negate the caching advantages HTTP/2 could provide and are unnecessary. It doesn't make HTTP/2 worse than HTTP/1.1. As for protocol turnover, arguably adopting SPDY was premature, but everyone knew it was when they did it. It'd be the same for someone who chooses to adopt QUIC now. One point of standardizing HTTP/2 was to let the more conservative among us start to use it now.

nickpsecurity 11y ago
Definitely. I actually gave them props for their SPDY work, including the name: it matching a common word would make it easier for lay people to remember. Many organizations and academics made alternatives to common protocols without the user base or influence to make them real. That Google was in a position to make things better, built a practical improvement, deployed it, and inspired the update to HTTP is a great credit to them. I wish more companies in similar positions would follow suit. And, hopefully, Google's experimentations in other protocols and domains will challenge those controlling the status quo to adapt to the times as well. Not holding my breath but it would be nice.
jack9 11y ago
It seems like he made fair points about HTTP2. The presentation urges change as a topic, but fails to provide compelling arguments to do so. Nowhere in there did he imply it was worse, nor did he "overblow" anything...multiple slides imply this is highly questionable advice dependent on current tech. 41-42 say "check for yourself or do your own way that's best for you based on your server for which we don't know enough" - Most of the time it works as well as http1.1 - so great. I'll keep doing that.
Silhouette 11y ago
All I really gathered from the presentation was that spriting and concatenation negate the caching advantages HTTP/2 could provide and are unnecessary. It doesn't make HTTP/2 worse than HTTP/1.1. But changing an existing production site so it no longer uses techniques like spriting and concatenation will damage performance if anything degrades the communications to HTTP/1.1. One point of standardizing HTTP/2 was to let the more conservative among us start to use it now. I'm not sure anyone who is switching to HTTP/2 today could reasonably be called "conservative". There are few production-level servers available yet, and some of the big potential performance wins due to the multiplexing, prioritisation and server push aspects -- the things that in theory could render those spriting and concatenation techniques obsolete -- are barely even mentioned right now outside of the standards documentation and related announcements. I just spent a few minutes searching to see how you'd actually configure a web server to implement customised server push for maximum performance, and I literally didn't find a single explanation, nor for that matter a single server even advertising the capability.

nickpsecurity 11y ago

Definitely. I actually gave them props for their SPDY work, including the name: it matching a common word would make it easier for lay people to remember. Many organizations and academics made alternatives to common protocols without the user base or influence to make them real. That Google was in a position to make things better, built a practical improvement, deployed it, and inspired the update to HTTP is a great credit to them. I wish more companies in similar positions would follow suit. And, hopefully, Google's experimentations in other protocols and domains will challenge those controlling the status quo to adapt to the times as well. Not holding my breath but it would be nice.

jack9 11y ago

It seems like he made fair points about HTTP2. The presentation urges change as a topic, but fails to provide compelling arguments to do so. Nowhere in there did he imply it was worse, nor did he "overblow" anything...multiple slides imply this is highly questionable advice dependent on current tech. 41-42 say "check for yourself or do your own way that's best for you based on your server for which we don't know enough" - Most of the time it works as well as http1.1 - so great. I'll keep doing that.

Silhouette 11y ago

All I really gathered from the presentation was that spriting and concatenation negate the caching advantages HTTP/2 could provide and are unnecessary. It doesn't make HTTP/2 worse than HTTP/1.1. But changing an existing production site so it no longer uses techniques like spriting and concatenation will damage performance if anything degrades the communications to HTTP/1.1. One point of standardizing HTTP/2 was to let the more conservative among us start to use it now. I'm not sure anyone who is switching to HTTP/2 today could reasonably be called "conservative". There are few production-level servers available yet, and some of the big potential performance wins due to the multiplexing, prioritisation and server push aspects -- the things that in theory could render those spriting and concatenation techniques obsolete -- are barely even mentioned right now outside of the standards documentation and related announcements. I just spent a few minutes searching to see how you'd actually configure a web server to implement customised server push for maximum performance, and I literally didn't find a single explanation, nor for that matter a single server even advertising the capability.