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

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

400 is for HTTP-level parsing issues; e.g., message delimitation -- at least from generic HTTP implementations. Not being able to parse an extension header is a totally different thing. 

By their nature, extensions need to be "safe" by default; i.e., if the extension isn't in use, the resulting behaviour shouldn't be bad -- because most of the Web won't exhibit the extension, at least at first.  So, if there's a parsing error, dropping the header *should* be safe as well.

I can see an argument that we should allow headers to say that in event of parsing failure, some status code should be generated, etc.; we should talk about that and figure out if it's a good idea. What I'd push back on is the notion that a header using SH should define more complex error handling such as dedup or fixup of the SH-defined parts; that's removing a good amount of value from SH.

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

Those things are necessary because CL et al were loosely specified at the start, and saw significant divergence in implementation at the same time that they saw wide deployment. That's not the case with SH; we're trying to define it tightly up-front so that such things are unnecessary. 


> Anyway I'm really not fine anymore with imagining that an agent along
> the chain would silently remove "Early-Data: 1, 1".

In SH, this would only be the parser that's actually consuming the header, not anyone along the chain, FWIW.

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

Early-Data doesn't use SH.

And, as above, intermediaries aren't expected to implement SH -- at least yet.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 15 May 2018 09:46:33 UTC