Re: New Draft: Using QUIC Stream Resets with Partial Delivery in HTTP/3

Hey,

Thanks for doing this. Overall the motivations that are captured looked good (IIRC these were discussed in early days of the RESET_STREAM_AT adoption in the QUIC WG). The guidance seems generally sound and there's probably some tweaks or polish that a WG might want to do. 

The security considerations should probably highlight the risks of sharing more information with a malicious peer (that otherwise would not be sent with regular RESET_STREAM). For example, the specific details of a rejection in response content might be abused (i.e., recon) but more concerningly it also creates a new opportunity for an attacker to trigger more state commitment required to reliably send that information. That's not a reason to not use RESET_STREAM_AT but is a new consideration worth highlighting.

On Mon, Jun 29, 2026, at 14:55, Marten Seemann wrote:
> Hi HTTP Working Group,
> 
> I’ve posted a new draft: “Using QUIC Stream Resets with Partial Delivery in HTTP/3”:
> https://datatracker.ietf.org/doc/draft-seemann-httpbis-reset-stream-at/
> 
> The draft describes how HTTP/3 can use the RESET_STREAM_AT QUIC extension when a stream needs to be reset, but a bounded prefix such as response headers, diagnostic data, or tunneled bytes should still be delivered reliably.
> 
> Feedback welcome,
> Marten