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