W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: Revising Structured Fields: scope

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Thu, 13 Oct 2022 05:42:37 +0000
Message-Id: <202210130542.29D5gbaI092977@critter.freebsd.dk>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC