5 ms·

So first Google (Chrome team) foobar'd HTTP (and HTML and CSS and ...) into overengineered crap to replace TCP with vague promises of pushed resources and multi

So first Google (Chrome team) foobar'd HTTP (and HTML and CSS and ...) into overengineered crap to replace TCP with vague promises of pushed resources and multiplexing only necessary to handle absurdly bloated CSS, images, and fonts there for CDNs by Google et al to sensor your traffic and visit data in the first place, then they admitted server push, as the other touted advantage, being not well thought out after all. The effect being to derail most F/OSS HTTP libs, web servers, and TCP/IP stacks due to sheer complexity and conflicting goals. Wish we'd call Google's destructive efforts towards the web as what they are.

omginternets 4y ago
Nit: I think you mean FUBAR. :)
- jonhohle 4y ago
  On a technology forum, `foobar` seems like an appropriate replacement.
gfodor 4y ago
Hey at least they’re killing it. Which would be, under the frame you’ve laid out here, a kind of progress?
yoro46 4y ago
>The effect being to derail most F/OSS HTTP libs, web servers, and TCP/IP stacks due to sheer complexity and conflicting goals. If you're trying to imply HTTP/2 and HTTP/3 have this goal, then I am glad you are not writing any HTTP libraries. I am sick and tired of everyone rolling their own shoddy, incomplete HTTP/1.1 libraries with string splitting and regex. I safely assume any HTTP library that does not support at least HTTP/2 is exactly this. I'm glad the "complexity" of HTTP/2 and HTTP/3 means less people are trying to make a half-assed implementation. By the time you get to actually sending stuff with HTTP/3, you'll be deep enough that you won't just forget the whole 3xx series of response codes.
- stingraycharles 4y ago
  This seems like a weird argument to make: complexity of a spec as some kind of gatekeeper to prevent people from rolling their own implementation? The fact of the matter is that these people will probably still not use HTTP/2, but rather stick with their broken HTTP/1.1 implementation, and therefor forever requiring browsers to support this.
1vuio0pswjnm7 4y ago
Well said. HTTP/1.1 or below is HTTP for the people, mostly developed by academia not "tech" companies or their service providers, e.g., CDNs. HTTP/2 and 3 are HTTP for "tech" companies and their service providers. If the technical limits of HTTP/1.1 limit the amount and effectiveness of online advertising and behavourial tracking, or if it limits the amount of time people may potentially waste on the "interactive" attention-grabbing www, then that is a benefit, IMHO. To put it another way, if the technical deficiencies of HTTP/1.1 limit the viability of "tech" companies then this is a benefit, because "tech" companies are responsible for attaching surveillance to commercial and recreational web use that I would prefer not to support. HTTP/1.1 and below were for a less commercial web not controlled by Google.
- charcircuit 4y ago
  You want websites to load slower and be worse to stick it to tech companies?
  - deleted 4y ago
    [deleted]
- 1vuio0pswjnm7 4y ago
  Websites "load" very fast for me because I do not use Chrome. I retreive data/information from the www without running Javascript, processing CSS or auto-loading resources. I have no trouble making online purchases, conducting online banking, etc. with a popular browser when that is necessary. The only regret is having to use a browser controlled by an advertising company (or supported by one) for those tasks. HTTP/1.1 works great for me.
  - charcircuit 4y ago
    I hope you realize what you do is extremely uncommon and that "the people" don't want the web to be like that where there is no styling, no images, no videos, limited interactivity, etc.
deleted 4y ago
[deleted]
Thorrez 4y ago
>replace TCP with vague promises of pushed resources Server Push was introduced in HTTP/2. TCP was replaced later, in QUIC and HTTP/3. The goal of replacing TCP was not to improve Server Push. Chrome never even implemented Server Push for HTTP/3. Disclosure: I work at Google but not on Chrome.
SquareWheel 4y ago
Even without Push, HTTP/2 is ridiculously faster than HTTP 1.1. Removing the parts that didn't work hardly seem like "overengineering". In fact, it's the opposite.
chrismorgan 4y ago
You are grossly misrepresenting the situation. Google has played a significant role in HTTP/2 and HTTP/3 development, and they did provide the starting point in each case, but they have not controlled it, and what has come out of IETF after collaboration with many interested parties is significantly different from what Google first proposed. And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3. And once talking about all this, the Chrome team is one of the less important parts of Google in bringing about HTTP/2 and HTTP/3. Yes, HTTP/2 and HTTP/3 are more complex than HTTP/1, but these are not the ways Google is harming the web—these are the good parts of what Google is helping to improve the web. You are yearning for the simple and inefficient days of yore, but those days are gone. The internet is a part of society now, and keeping it inefficient and slow does no one any good. Your tirade is misguided and significantly factually inaccurate.
- trasz 4y ago
  >And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3. So would it happen if Google wasn't involved?
  - chrismorgan 4y ago
    Google served as a well-placed catalyst, due to their broad interests. I don’t doubt that it would have taken longer to happen had they not been involved (though what “involved” means is fiddly, given that being deliberately not-involved would act as a significant retarding force, given the popularity of their browser), but I do believe that it would still have happened eventually. (The word catalyst isn’t quite right because Google took part in the reaction, but it’s the closest word to what I want that I can immediately think of.)
    - trasz 4y ago
      “Oxidizer”, perhaps? ;-)
- mwcampbell 4y ago
  The GP got the facts wrong, but IMO we shouldn't dismiss the sentiment. In particular: > You are yearning for the simple and inefficient days of yore The simpler our systems are, the more we can understand them, and the more reliable we can make them. And more often than not, a system that's simple from top to bottom, and kept as small as possible, is efficient. Yes, I do kind of miss the days when HTTP was understandable enough that I could write my own HTTP server directly on top of a TCP socket API. TLS is a necessary evil to protect users from bad actors, but I'm not so sure about HTTP/2. In one of my Rust projects, I just switched from reqwest to ureq (yes, partly prompted by this discussion), and saved ~600K in a release build (already optimized for size). That's 600K of removed code that can't cause bugs anymore. And I know that in my particular use case, HTTP/1.1 will be good enough.

omginternets 4y ago

Nit: I think you mean FUBAR. :)

jonhohle 4y ago
On a technology forum, `foobar` seems like an appropriate replacement.

gfodor 4y ago

Hey at least they’re killing it. Which would be, under the frame you’ve laid out here, a kind of progress?

yoro46 4y ago

>The effect being to derail most F/OSS HTTP libs, web servers, and TCP/IP stacks due to sheer complexity and conflicting goals. If you're trying to imply HTTP/2 and HTTP/3 have this goal, then I am glad you are not writing any HTTP libraries. I am sick and tired of everyone rolling their own shoddy, incomplete HTTP/1.1 libraries with string splitting and regex. I safely assume any HTTP library that does not support at least HTTP/2 is exactly this. I'm glad the "complexity" of HTTP/2 and HTTP/3 means less people are trying to make a half-assed implementation. By the time you get to actually sending stuff with HTTP/3, you'll be deep enough that you won't just forget the whole 3xx series of response codes.

stingraycharles 4y ago
This seems like a weird argument to make: complexity of a spec as some kind of gatekeeper to prevent people from rolling their own implementation? The fact of the matter is that these people will probably still not use HTTP/2, but rather stick with their broken HTTP/1.1 implementation, and therefor forever requiring browsers to support this.

1vuio0pswjnm7 4y ago

Well said. HTTP/1.1 or below is HTTP for the people, mostly developed by academia not "tech" companies or their service providers, e.g., CDNs. HTTP/2 and 3 are HTTP for "tech" companies and their service providers. If the technical limits of HTTP/1.1 limit the amount and effectiveness of online advertising and behavourial tracking, or if it limits the amount of time people may potentially waste on the "interactive" attention-grabbing www, then that is a benefit, IMHO. To put it another way, if the technical deficiencies of HTTP/1.1 limit the viability of "tech" companies then this is a benefit, because "tech" companies are responsible for attaching surveillance to commercial and recreational web use that I would prefer not to support. HTTP/1.1 and below were for a less commercial web not controlled by Google.

charcircuit 4y ago
You want websites to load slower and be worse to stick it to tech companies?
- deleted 4y ago
  [deleted]
1vuio0pswjnm7 4y ago
Websites "load" very fast for me because I do not use Chrome. I retreive data/information from the www without running Javascript, processing CSS or auto-loading resources. I have no trouble making online purchases, conducting online banking, etc. with a popular browser when that is necessary. The only regret is having to use a browser controlled by an advertising company (or supported by one) for those tasks. HTTP/1.1 works great for me.
- charcircuit 4y ago
  I hope you realize what you do is extremely uncommon and that "the people" don't want the web to be like that where there is no styling, no images, no videos, limited interactivity, etc.

deleted 4y ago

[deleted]

Thorrez 4y ago

>replace TCP with vague promises of pushed resources Server Push was introduced in HTTP/2. TCP was replaced later, in QUIC and HTTP/3. The goal of replacing TCP was not to improve Server Push. Chrome never even implemented Server Push for HTTP/3. Disclosure: I work at Google but not on Chrome.

SquareWheel 4y ago

Even without Push, HTTP/2 is ridiculously faster than HTTP 1.1. Removing the parts that didn't work hardly seem like "overengineering". In fact, it's the opposite.

chrismorgan 4y ago

You are grossly misrepresenting the situation. Google has played a significant role in HTTP/2 and HTTP/3 development, and they did provide the starting point in each case, but they have not controlled it, and what has come out of IETF after collaboration with many interested parties is significantly different from what Google first proposed. And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3. And once talking about all this, the Chrome team is one of the less important parts of Google in bringing about HTTP/2 and HTTP/3. Yes, HTTP/2 and HTTP/3 are more complex than HTTP/1, but these are not the ways Google is harming the web—these are the good parts of what Google is helping to improve the web. You are yearning for the simple and inefficient days of yore, but those days are gone. The internet is a part of society now, and keeping it inefficient and slow does no one any good. Your tirade is misguided and significantly factually inaccurate.

trasz 4y ago
>And Google is far from the only party that wants, uses and will benefit from HTTP/2 and HTTP/3. So would it happen if Google wasn't involved?
- chrismorgan 4y ago
  Google served as a well-placed catalyst, due to their broad interests. I don’t doubt that it would have taken longer to happen had they not been involved (though what “involved” means is fiddly, given that being deliberately not-involved would act as a significant retarding force, given the popularity of their browser), but I do believe that it would still have happened eventually. (The word catalyst isn’t quite right because Google took part in the reaction, but it’s the closest word to what I want that I can immediately think of.)
  - trasz 4y ago
    “Oxidizer”, perhaps? ;-)
mwcampbell 4y ago
The GP got the facts wrong, but IMO we shouldn't dismiss the sentiment. In particular: > You are yearning for the simple and inefficient days of yore The simpler our systems are, the more we can understand them, and the more reliable we can make them. And more often than not, a system that's simple from top to bottom, and kept as small as possible, is efficient. Yes, I do kind of miss the days when HTTP was understandable enough that I could write my own HTTP server directly on top of a TCP socket API. TLS is a necessary evil to protect users from bad actors, but I'm not so sure about HTTP/2. In one of my Rust projects, I just switched from reqwest to ureq (yes, partly prompted by this discussion), and saved ~600K in a release build (already optimized for size). That's 600K of removed code that can't cause bugs anymore. And I know that in my particular use case, HTTP/1.1 will be good enough.