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