- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 2 Mar 2026 23:21:14 +0100
- To: Lucas Pardue <lucas@lucaspardue.com>
- Cc: Sean McArthur <sean@seanmonstar.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Lucas, On Mon, Mar 02, 2026 at 09:51:04PM +0000, Lucas Pardue wrote: > On Mon, Mar 2, 2026, at 21:44, Sean McArthur wrote: > > It reads like you can send the END_STREAM flag on the HEADERS frame, without END_HEADERS, and then send CONTINUATION frames, and when they end, the stream ends. > > > > https://httpwg.org/specs/rfc9113.html#HEADERS > > > > > A HEADERS frame with the END_STREAM flag set signals the end of a stream. However, a HEADERS frame with the END_STREAM flag set can be followed by CONTINUATION frames on the same stream. Logically, the CONTINUATION frames are part of the HEADERS frame. > Thanks Sean, I missed that! Also seems reinforced by > https://www.rfc-editor.org/rfc/rfc9113.html#section-8.1-5 Yeah I also missed it when first trying to implement CONTINUATION in haproxy a few years ago and found this approach very confusing. It does have some logic (i.e. ES is only on HEADERS) but is counter-intuitive, to say the least. I think the rationale comes from the fact that you're supposed to know when starting to serialize your headers whether the stream ends here or not, and that since you're forced to send only CONTINUATION after a missing EH, in practice CONTINUATION only serves to split a large headers block into multiple frames respecting the max frame size, so it's just an artificial way to represent a larger HEADERS frame, and in this case it sort of makes sense to keep ES on the HEADERS frame and not on CONTINUATION. Just my two cents, Willy
Received on Tuesday, 3 March 2026 03:49:40 UTC