HTTP request lifecycle

[lucacasonato]

1. Client sends request headers to the server (h1/h2/h3) -> url, headers, whether a body is present, and req.connection
2. Client can send a body (optional) (h1/h2/h3)

• h1 either streaming (transfer-encoding: chunked) or fixed size (content-length)
• h2/h3 are always streaming, but could have a size indication (content-length)

3. Server could respond with client hints before the real response (How to send early hints #4)
4. Server could respond with status code + headers (even before the full client body is at the server, or even has been sent), additionally specify which trailer "headers" you want respond with (Trailer support in the API whatwg/fetch#981)
5. Server can respond with a body or upgrading the connection to a different protocol (which would have to be advertised through upgrade header).
6. Server is done sending the response body or the upgraded connection closes.
7. Respond with trailers that you advertised

1 must happen before 3 and 4, and 6 stops 2.

[lucacasonato]

• Basic req with no body, server responds with status code + headers + body
• Streaming req body, server responds with status code + headers + body
  • The request body must not outlive the response body (it must complete before the response body).
• Upgrade request, server responds with status code + headers, and upgrades the connection
  • Lifetime of the req/resp is now bound to the upgraded socket
• Client sends request, server responds with early hint, server responds with status code + headers + body