Re: [Technical Errata Reported] RFC7231 (4031)

On 1 Jul 2014, at 4:34 am, Barry Leiba <> 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.


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


Mark Nottingham

Received on Tuesday, 1 July 2014 03:20:51 UTC