bt90

The naïve approach would be to have an object which stores all the filesystem metadata and maybe even precomputed block hashes. If we really want to mimic a POSIX filesystem.

The headers as seen by traefik/quiche would be interesting. At least the outgoing request from traefik to httpbin looks malformed: ``` 'Content-Length': ['0'], ``` Maybe it's even sending the body,...

> If we send request with chunked body to the http3.Server. Isn't chunked transfer prohibited in HTTP/3? Edit: [RFC9114 section 4.1. ](https://datatracker.ietf.org/doc/html/rfc9114#name-http-message-framing) > Transfer codings (see [Section 7](https://www.rfc-editor.org/rfc/rfc9112#section-7) of [[HTTP/1.1](https://datatracker.ietf.org/doc/html/rfc9112)])...

[RFC9114 Section 4.2](https://datatracker.ietf.org/doc/html/rfc9114#name-http-fields) doesn't list them explicitly, but refers to them as `connection-specific header fields` and links to [RFC9110 Section 7.6.1](https://datatracker.ietf.org/doc/html/rfc9110#name-connection).

It may seem obvious, but we should also throw an error if we are running as a client and these headers are passed to the request. We shouldn't rely on...

I guess the QUIC layer is completely out of scope at this point?

Terminating the QUIC stream with `H3_MESSAGE_ERROR` would be the correct thing to do according to the spec.

Now I get it. This client/server receive/respond mix tends to get a bit confusing from time to time. So we're able to properly reject them as we receive them as...

Talking about the principle of least surprise: if there's no body, I'd be surprised if the length was marked as unknown. A missing body has a known length of 0...

I haven't looked into it, but RFC7230 has largely been superseded by RFC9110. https://datatracker.ietf.org/doc/html/rfc9110#name-content-length