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

On Tue, May 15, 2018 at 04:39:05PM +1000, Mark Nottingham wrote:
> 
> 
> > On 15 May 2018, at 4:11 pm, Willy Tarreau <w@1wt.eu> wrote:
> > 
> > On Tue, May 15, 2018 at 03:42:10PM +1000, Mark Nottingham wrote:
> >> SH doesn't allow empty header fields, FWIW.
> >> 
> >> We also don't have boolean values, but it seems trivial to use an integer.
> > 
> > Sure but integer also means parsing, deduplicating, and error path for
> > what doesn't parse according to expectations.
> 
> But all of those things are already defined by SH for integers..
> 
> > Supporting boolean values
> > "header field is present and non empty" could really be useful IMHO.
> 
> I think the question is whether they're useful enough -- as compared to just
> using an integer with a value constrained to 0 or 1 -- that it justifies the
> extra machinery (in the spec and in implementations).

But we're back to the problem Julian raised which is :

    When Structured Headers parsing fails, the header is discarded

Booleans are different from integers. Booleans indicate a status. Eg:
"safe" vs "unsafe". Discarding the "unsafe" status because we failed to
parse it is dangerous. Actually I'm starting to think that the rule
consisting in silently discarding a header field that fails to parse is
the problem here. Normally we're supposed to return "400 bad req" on
parsing errors, and I fear we're becoming too lenient on parsing and
introduce a new class of problems.

I'd rather be a bit stricter by suggesting that if a recipient fails
to parse a header field, it may attempt to fix it according to a number
of well-established rules (eg deduplicate it if it's supposed to be
unique as 7230 does for Content-Length), or fail with 400 bad req.

Anyway I'm really not fine anymore with imagining that an agent along
the chain would silently remove "Early-Data: 1, 1". This causes a big
issue. Either we fix it or we reject. And given that this error might
be caused by an intermediary possibly not really impacted by Early-Data
but just aware that it's supposed to be an integer and wanting to fix
it, there's no way we can even expect this intermediary to comply with
specific provisions made in the Early-Data spec, so it clearly is SH
that must prevent this from happening.

Cheers,
Willy

Received on Tuesday, 15 May 2018 09:35:17 UTC