[game-of-throws]

> Why Do We Need Trailers At All?

The author convinced they're needed. But I wonder if some sort of error signaling should have been baked into `Transfer-Encoding: chunked` instead. It wouldn't have made sense in HTTP/1.1 since you can just close the connection. But in later HTTP versions with pipelined requests, I can see the use for bailing on one request while keeping the rest alive.

[adev_]

> The author convinced they're needed. But I wonder if some sort of error signaling should have been baked into `Transfer-Encoding: chunked` instead. It wouldn't have made sense in HTTP/1.1 since you can just close the connection. But in later HTTP versions with pipelined requests, I can see the use for bailing on one request while keeping the rest alive.

It did not to me.

I would rephrase the argumentation as:

- In HTTP/2 we thought to be smart by multiplexing multiple HTTP transactions over a single TCP connection.

- Shit we realized later that HTTP/1.1 did not necessitate trailers because they could abort the connection and we can not afford to do that anymore, we are multiplexed now.... Shit, we do need trailers now.

->

- That is currently a good example of good intentions inducing complexity. And complexity inducing even more complexity for free.

- HTTP/2 is now rolled over the world and everybody has to deal with that

- Still HTTP/2 suffers of several problems completely ignored by the blog post (Like the Head-of-Line blocking problem: it is not solved in HTTP/2). The result is now QUIC + HTTP/3 and we all start over again.

[Thorrez]

>Shit we realized later that HTTP/1.1 did not necessitate trailers because they could abort the connection and we can not afford to do that anymore

This is an interesting point, but I don't think it's correct. The HTTP/2 spec allows you to send a RST_STREAM frame to indicate that an individual stream had a problem. To be contrasted with an END_STREAM frame that indicates an individual stream ended successfully.

https://www.rfc-editor.org/rfc/rfc7540.html

[hnov]

Right, the author seems to be unfamiliar with H2, which is bizarre for someone who worked on gRPC.

[xyzzyz]

> Like the Head-of-Line blocking problem: it is not solved in HTTP/2

How so? It is not solved on the network level (due to its use of TCP), but it is solved on application layer: slow response to one request is not blocking other requests.

[adev_]

> How so? It is not solved on the network level (due to its use of TCP), but it is solved on application layer: slow response to one request is not blocking other requests.

Like you said, it does not solve the network level:

- in HTTP/2, A packet drop will slow down every HTTP transaction.

- In HTTP/1 with a session pool (The usual web browser way of doing thing), it will slow down only one over X (X, size of the pool).

This has been found to be a big problem over (unreliable) mobile network and that makes HTTP/2 sometimes even worst than HTTP/1.

http://nl.cs.montana.edu/lab/publications/Goel_H2_extended.p...