- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Thu, 13 Oct 2022 05:42:37 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
-------- Willy Tarreau writes: > I would really > like it if we would remove that limitation so that we could hope to more > easily retrofit other fields there, and it doesn't seem like too complicated > change to me to simply add "sf-empty" to the bare-item definition, which > would likely solve this. I fear that codifying that would encourage more headers with such behaviour, which I assume we do not want ? I would far prefer to let the very few headers which has this behaviour be special-cased in their own definition. If I am wrong about that, and if you mean something like adding in 4.1: 0. If the structure value is sf-empty, return an empty string. and in 4.2: 1a. If sf-empty is a permissible field value and input_string consists entirely of SP characters, return sf-empty. That seems mostly harmless to me. If you want sf-empty anywhere else, I am a firm NO, because it would require significant work to redefine inner_list and maybe other places. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 13 October 2022 05:42:54 UTC