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:06:30 +0200
To: Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6b617854-7b71-732f-fb2c-ded248399cb8@gmx.de>
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.

It might make sense to define a new 4xx code to cover the case of a 
syntax error in a request header field value.

 > ...

Best regards, Julian
Received on Tuesday, 15 May 2018 10:07:27 UTC

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