W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: draft-ietf-httpbis-replay-03, "5.1. The Early-Data Header Field"

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 13 May 2018 12:16:57 +0200
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Julian Reschke <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20180513101657.GA21542@1wt.eu>
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.

>   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.

I agree.

Willy
Received on Sunday, 13 May 2018 10:17:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC