- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 9 Oct 2025 15:38:54 +1300
- To: ietf-http-wg@w3.org
On 08/10/2025 06:14, David Schinazi wrote: > I could see not wanting > this feature in the base protocol because the base protocol was intended > to be as general purpose as possible, and that change would > have required all receivers to implement it, but this is an extension > that not every implementation needs to support. BUT this is a stream level mechanism. That means even one implementation along one chain of HTTP agents not supporting it "Breaks the Internet" for either the client or the application trying to use it. Having both client and application use unbounded **optionally** means they have already mandatory support for not using it. And can cope without it just fine already - ergo no need for the extension to exist. Consider a "blind" intermediary relaying at full bandwidth capacity a single stream. Along comes a second stream with a high priority transaction. The DATA frames allow this intermediary to immediately drop PRIORITY_UPDATE on the stream #1 sender while that urgent transaction completes. Then restore to full service. The UNBOUNDED_DATA frames would continue to flow into UDP/QUIC buffer and force their handling at topmost priority. Leaving the actual high priority traffic in the region of potentially dropped packets. In todays network intermediaries have the situation where online streams video traffic compete with admin managing virtual servers. Priority management over streams has become a critical ability. So yeah there is some "pushback" on anything being unbounded. HTH Amos
Received on Thursday, 9 October 2025 02:39:03 UTC