- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 15 May 2018 11:28:28 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 15, 2018 at 05:19:15PM +1000, Mark Nottingham wrote: > > > > On 15 May 2018, at 5:13 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > > > On 2018-05-15 09:03, Mark Nottingham wrote: > >> On 15 May 2018, at 5:00 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > >>> > >>> On 2018-05-15 07:42, Mark Nottingham wrote: > >>>> SH doesn't allow empty header fields, FWIW. > >>>> ... > >>> > >>> ...which makes it incompatible with the list rule in RFC 7230, no? > >> In what sense? > > > > Because it says, that if you header is defined as > > > > #token > > > > you can send > > > > Foo: a > > Foo: > > Foo: b > > > > and it would be equivalent to > > > > Foo: a, b > > Ah. > > I didn't mean "empty header fields" in that sense -- rather, just > > Foo: FWIW I've used many times "Host:" with no name when connecting to an HTTP/1.1 server without knowing its name, and rarely faced any issue with this. I'm not saying it's right or wrong, but that many implementations support an empty header field and distinguish it from an absent one. Willy
Received on Tuesday, 15 May 2018 09:29:06 UTC