W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: [Technical Errata Reported] RFC7231 (4031)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Jul 2014 13:20:16 +1000
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>
Message-Id: <A048F0CB-E800-4FFD-9000-58B15A1BCE31@mnot.net>
To: Barry Leiba <barryleiba@computer.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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC