Thanks for building this small-but-useful component for HTTP signaling. I have only a few minor suggestions from my review. I note that there is a tension as to whether this header "instructs" intermediaries to process messages incrementally or "requests" them to do so. Given that such intermediaries might not be under the same control as the message sender (in one or both directions), "instructs" seems like it might imply authority the sender doesn't have. Therefore, I'd suggest using the word "request" throughout. As a related note, I appreciate that you've defined intermediary behavior when it understands the requested handling and declines to comply. Given that this might be in reaction to a message header in a response, some indication to the server that the remainder of its response will not be required could be useful if the transport supports it -- this might be a stream action, such as a QUIC STOP_SENDING frame. When discussing this fail-fast behavior, it might also be worth clarifying that this applies exclusively to an intermediary which is aware of and supports this field. Obvious, but otherwise we have a MUST that could be read as directed to a non-implementing party. None of this is blocking; I leave it to the authors' discretion whether you'd like to take any action on this feedback prior to Last Call. Let me know when you're ready to proceed. Thanks, Mike Bishop (as Responsible AD)
Received on Friday, 21 November 2025 20:05:12 UTC