Marten Seemann

> Anyone here has a suspicion? Might have been padding. As a side note: I've long argued that adding padding outside of the QUIC envelope is lazy, and leads to...

This looks interesting: The packet is getting buffered, and apparently we never retrieve it from the buffer. I went through the respective code paths multiple times - and they look...

This is a TCP simultaneous connect, as @Stebalien said. We had a proposal somewhere to handle this gracefully, but it was never implemented.

Which value should we send in the SETTINGS frame? https://datatracker.ietf.org/doc/html/rfc9114#header-size-constraints

> From this [comment](https://github.com/quic-go/quic-go/issues/2424#issuecomment-664067815), it seems currently only static table is used when decoding request headers. > > > Right now, the qpack implementation only uses the static table for...

Thank you for providing these links, I think this logic is very clean and straightforward, and it remains valid even when we implement the QPACK dynamic table, as it operates...

I'd like to keep this logic out of the qpack package. How about this: * `qpack.Decoder.Write` doesn't trigger any decoding. The `Decoder` just saves the byte slice. * introduce `qpack.Decoder.NextHeaderField()...

Unassigning from @jannis-seemann, since I haven't seen any update in a long time.

Unfortunately, it's a bit more complicated than that. First of all, dropped packets is something completely different from lost packets. It refers to packets that we _intentionally_ drop, for a...

Let's not close this. This is a totally valid feature request.