- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 1 Jul 2014 13:20:16 +1000
- To: Barry Leiba <barryleiba@computer.org>
- Cc: "Julian F. Reschke" <julian.reschke@greenbytes.de>, RFC Errata System <rfc-editor@rfc-editor.org>, Roy Fielding <fielding@gbiv.com>, Pete Resnick <presnick@qti.qualcomm.com>, annevk@annevk.nl, HTTP Working Group <ietf-http-wg@w3.org>
On 1 Jul 2014, at 4:34 am, Barry Leiba <barryleiba@computer.org> wrote: > Now (it's "below"), the tricky bit is that it's in the best interest > of interoperability for parsers to tolerate things like that -- > perhaps not as ridiculous as the example above, but something like > this: > > Content-Type: text/plain; charset=iso8859-1; > > ...which would be invalid according to the grammar in 7231, but which > some implementors might produce because they misread things, > misunderstood things, or whatever. It'd be nice if we could tell > parsers to be lenient. I'm not sure how to do that. I'm sure that > tweaking the production grammar isn't the right answer. And I'm sure > that whatever the right answer is, it *is* out of scope for errata. > Perhaps a separate document? Right now, all we say about this in most cases (excepting those where security is an issue, e.g., Host) is here: > Unless noted otherwise, a recipient may attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous. <http://httpwg.github.io/specs/rfc7230.html#conformance> Anne, is there security impact here? If not, I think Barry and Julian have convinced me it's probably not errata against this spec. I could see us starting work on a "Tolerant HTTP Header Field Parsing" spec if there's sufficient interest; it's a pretty thankless task, but personally I think it'd be worthwhile, and would contribute. We can spend a few minutes in Toronto on this if anyone else is interested... Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 1 July 2014 03:20:51 UTC