- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 14 May 2018 08:45:11 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 13 May 2018, at 8:16 pm, Willy Tarreau <w@1wt.eu> wrote: > > On Sun, May 13, 2018 at 08:10:34PM +1000, Martin Thomson wrote: >> On Sun, May 13, 2018 at 2:38 PM Willy Tarreau <w@1wt.eu> wrote: >>>> Just to make sure that Structured Headers is fit for purpose (i.e., not >> trying to get adoption here!), *if* this header were based upon SH, would >> its current design be adequate? >>>> >>>> I think so, just want to make sure. >> >>> I think so as well. >> >> Quoting: "header field authors are encouraged to clearly state additional >> constraints upon the syntax, as well as the consequences when those >> constraints are violated" >> >> It seems to me like we've done that. Note that we're suggesting a >> contradictions with this though: "If parsing fails - including when calling >> another algorithm - the entire header field's value MUST be discarded." > > Indeed, this rule may have some nasty side effects if it causes the loss > of a header field serving as a signal. The idea here is that if you're using SH, you defer to it for error handling of this nature, and that error handling is, shall we say, quite "crisp." As long as parser end of the connection is using SH implementations and those implementations are reasonably conformant, you should get decent interop, since non-conformant headers will fail consistently and hard. > >> And I'm OK with that in this case. Were we to cite structured headers, we >> would probably want to call out that direct contravention. My assumption was that if this spec were using SH, you wouldn't need to say anything beyond 'this is the structure we expect:...". Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Sunday, 13 May 2018 22:45:43 UTC