- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 May 2025 10:02:17 +1000
- To: "Andrew (andy) Newton" <andy@hxr.us>
- Cc: The IESG <iesg@ietf.org>, ietf-http-wg@w3.org, tpauly@apple.com
Hi Andy, > On 6 May 2025, at 3:17 am, Andrew (andy) Newton <andy@hxr.us> wrote: > > If there are no maximums, there appears to be some undocumented point when these values become ignored. And if they are ignored, there isn't a mechanism to communicate that they are being ignored, correct? Is that not an interoperability concern? Yes, but this is a limit of HTTP itself, as deployed -- implementations as well as deployments can and very much do impose arbitrary limits on sizes of various aspects of headers -- e.g., individual line lengths, individual value lengths (both before and after combination), number of lines, and overall header block size. Anything we specify in this document can be overridden by those limits, and thus cannot be relied upon. Furthermore, HTTP is used in a wide variety of applications, not just the Web. A limit that might make sense for a consumer Web site might be completely inappropriate for an enterprise messaging system built on top of HTTP. We cannot take a one-size-fits-all approach, which is why we see application-focused specifications like Fetch from the WHATWG placing additional constraints on the protocol. Finally, understand that often, a maximum value length constraint is being imposed by software that's focused on security, such as a Web Application Firewall (WAF). Documenting that maximum length will be seen as an inducement for attackers to send a value that's just under that size, and there will then be a strong incentive for WAFs to consider traffic that's slightly undersize as an attack, which means that the documented maximum couldn't be relied upon. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 6 May 2025 00:02:26 UTC