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: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 15 May 2018 12:34:36 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, Kazuho Oku <kazuhooku@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <4d0b3165-4265-9963-8ae5-72d9b0d2d980@gmx.de>
On 2018-05-15 12:18, Mark Nottingham wrote:
>> On 15 May 2018, at 8:06 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>> On 2018-05-15 11:46, Mark Nottingham wrote:
>>>> 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.
>> 400 is for anything caused by the client, and not covered by a more specific 4xx code.
> Yes, but its use is not required upon any error by the client.

Right. I was just disagreeing with "400 is for HTTP-level parsing 
issues; e.g., message delimitation -- at least from generic HTTP 

>> It might make sense to define a new 4xx code to cover the case of a syntax error in a request header field value.
> Do we have examples of extension headers needing / doing this?
> None of the ones in recent memory do (e.g., Access-Control-Allow-*, Accept-Patch, Accept-Post, ALPN, Alt-Used, Cookie (bis), HTTP2-Settings, Origin, Prefer).
> That's not to say that we'll never encounter another header that justifies a hard error reflected in a status code, just that it doesn't seem common, so we might be optimising (well, specifying) prematurely here.
> I would say we could define a "SH-Errors-Encountered" header to stick onto a 400, but I think that creates a more complex, coupled protocol than we want here (YMMV), and it would encourage header authors to generate that 400, rather than having safe defaults -- which is I think the pattern we want them to be following.

...well, we got here because we were discussing error handling for 
malformed Early-Data header fields. If Early-Data was using SH, this 
would be an example.

Best regards, Julian
Received on Tuesday, 15 May 2018 10:35:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC