5 ms·

HTTP/2 Brings Rapid Reset Misery

2 points by CrankyBear 3y ago

1vuio0pswjnm7 3y ago
"While the victims - Amazon Web Services (AWS), Cloudflare, and Google Cloud - were able to fight these monster attacks off, the same attacks are more than capable of blowing away less well-prepared websites and services." One could argue HTTP/2 was designed by Big Tech/Big CDNs (Google, Akamai, etc.) for Big Tech/Big CDNs. "With HTTP/1, the wire format is quite simple. It uses a serialized stream of ASCII characters, sent over a reliable transport layer, typically TCP. Request and response messages are exchanged. While a single TCP connection can exchange multiple requests and responses, in HTTP/1, each message must be sent as a whole in a strict order. This means these messages are exchanged serially and can not be multiplexed." This might make little sense for a "web browser" used to access "interactive" webpages full of Javascript, behavioural tracking and advertising coming from various domains. However it's quite useful when retrieving files, e.g, HTML, JSON, plaintext. Using HTTP/1 I retrieve hundreds of files noninteractively and sequentially in a single TCP connection and compress the output into a single .zst file with zstd. This is highly space efficient. The data can then be searched quickly with zstdgrep. Because it is stored sequentially, it can easily be processed into other formats such as SQL, CSV, or simple(r) HTML containing only the elements I want. I can then discard the .zst file. All of this is easily automated. Goodbye web cruft. HTTP/2 and HTTP/3 are marketed with some claim about "make the web faster". But it stands to reason that first one needs to examine why the web would be slow. The reason the web slow for some people is because of too much Javascript and remotely-hosted advertising used by web developers. Thus, HTTP/2 does not seek to make the web faster by removing what is making it slow. It assumes those bottlenecks must remain. A direct result of web developers who seek to profit from advertising. But the worst aspect of HTTP/2 is that it tried to remove user agency. Currently, Javascript is widely used to diminish user agency. When a web user makes an HTTP request for a webpage, the web browser automatically runs Javascript provided by web developers that makes more HTTP requests not intitiated by the web user. The web user has no idea what those additional requests will be when she requests the page. With HTTP/2, this removal of user agency, i.e., those additional requests for advertising or telemetry, not initiated by the web user, are anticipated by the HTTP protocol itself. The protocol designers believe the additional requests, i.e., what makes the web slow, are not optional. The HTTP/2 protocol initially called for a feature known as "server push" that would have codified the removal of user agency into the protocol. It was later removed. Server push was another defect in HTTP/2. How many more are yet to come. The rapid reset issue seems to suggest there is still an assumption that user agency is diminished going forward. HTTP/2 fails to consider that the web user would be in control of all the HTTP requests sent and, optionally, cancelled. It presumes web developers are the ones controlling the number of HTTP requests and cancellations. All this is result of so-called "tech" companies that have no viable business model other than programmatic online advertising. HTTP/1 fulfilled the goal of the web as a public resource. Thus, a web user can use it to noninteractuvely retrieve public, noncommercial data without subjecting themselves to constant surveillance as they use the data. HTTP/2's goal, on the other hand, is to optimise the web for advertising. It only contemplates a commercial web where user are under constant surveillance.

2 points by CrankyBear 3y ago

"While the victims - Amazon Web Services (AWS), Cloudflare, and Google Cloud - were able to fight these monster attacks off, the same attacks are more than capable of blowing away less well-prepared websites and services." One could argue HTTP/2 was designed by Big Tech/Big CDNs (Google, Akamai, etc.) for Big Tech/Big CDNs. "With HTTP/1, the wire format is quite simple. It uses a serialized stream of ASCII characters, sent over a reliable transport layer, typically TCP. Request and response messages are exchanged. While a single TCP connection can exchange multiple requests and responses, in HTTP/1, each message must be sent as a whole in a strict order. This means these messages are exchanged serially and can not be multiplexed." This might make little sense for a "web browser" used to access "interactive" webpages full of Javascript, behavioural tracking and advertising coming from various domains. However it's quite useful when retrieving files, e.g, HTML, JSON, plaintext. Using HTTP/1 I retrieve hundreds of files noninteractively and sequentially in a single TCP connection and compress the output into a single .zst file with zstd. This is highly space efficient. The data can then be searched quickly with zstdgrep. Because it is stored sequentially, it can easily be processed into other formats such as SQL, CSV, or simple(r) HTML containing only the elements I want. I can then discard the .zst file. All of this is easily automated. Goodbye web cruft. HTTP/2 and HTTP/3 are marketed with some claim about "make the web faster". But it stands to reason that first one needs to examine why the web would be slow. The reason the web slow for some people is because of too much Javascript and remotely-hosted advertising used by web developers. Thus, HTTP/2 does not seek to make the web faster by removing what is making it slow. It assumes those bottlenecks must remain. A direct result of web developers who seek to profit from advertising. But the worst aspect of HTTP/2 is that it tried to remove user agency. Currently, Javascript is widely used to diminish user agency. When a web user makes an HTTP request for a webpage, the web browser automatically runs Javascript provided by web developers that makes more HTTP requests not intitiated by the web user. The web user has no idea what those additional requests will be when she requests the page. With HTTP/2, this removal of user agency, i.e., those additional requests for advertising or telemetry, not initiated by the web user, are anticipated by the HTTP protocol itself. The protocol designers believe the additional requests, i.e., what makes the web slow, are not optional. The HTTP/2 protocol initially called for a feature known as "server push" that would have codified the removal of user agency into the protocol. It was later removed. Server push was another defect in HTTP/2. How many more are yet to come. The rapid reset issue seems to suggest there is still an assumption that user agency is diminished going forward. HTTP/2 fails to consider that the web user would be in control of all the HTTP requests sent and, optionally, cancelled. It presumes web developers are the ones controlling the number of HTTP requests and cancellations. All this is result of so-called "tech" companies that have no viable business model other than programmatic online advertising. HTTP/1 fulfilled the goal of the web as a public resource. Thus, a web user can use it to noninteractuvely retrieve public, noncommercial data without subjecting themselves to constant surveillance as they use the data. HTTP/2's goal, on the other hand, is to optimise the web for advertising. It only contemplates a commercial web where user are under constant surveillance.