- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 13 Oct 2022 16:44:04 +1100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Just to add -- there's a BIG difference between adding a new datatype that headers can opt into, and changing the parsing algorithm for existing types. IMO we should be extremely wary about doing the latter, and we've already discussed this issue quite a bit. Cheers, > On 13 Oct 2022, at 4:42 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > 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. -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 13 October 2022 05:44:22 UTC