- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 18 Jun 2020 12:01:13 +0200
- To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "yoav@yoav.ws" <yoav@yoav.ws>
- Cc: "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-httpbis-client-hints@ietf.org" <draft-ietf-httpbis-client-hints@ietf.org>, "mnot@mnot.net" <mnot@mnot.net>
On 18.06.2020 10:35, Magnus Westerlund wrote: > ... > No, I am simply noting that by using structured field values your implicitly > restriciting the syntax from what RFC 7230 allows for field names, which is: > > header-field = field-name ":" OWS field-value OWS > field-name = token > where token is: > > token = 1*tchar > > tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" > / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" > / DIGIT / ALPHA > ; any VCHAR, except delimiters > > > However Structure field's token definition is this: > > > sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" ) > > Thus, Client hints will not be able to do express all possible field-names that > may exist in HTTP. > > From that I was asking: > > Where there any discussion of this restriction? > Where there any concerns raised with this, or are all okay with it? > > I personally don't have an issue with it as all registered HTTP headers will > fitt in this more restricted syntax. > ... FWIW, an alternative approach would be to allow both sf-token and sf-string here (I'm not saying it is needed, but it would certainly resolve the issue). Best regards, Julian
Received on Thursday, 18 June 2020 10:01:36 UTC