Subject: Re: [Technical Errata Reported] RFC7231 (4031)

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Jun 2014 21:04:26 +1000

My .02 -

I think this makes sense technically; Julian, have you tested this?

As an errata, I think it also makes sense, although I will defer to the Robed Ones for a ruling on that…

Cheers,

On 30 Jun 2014, at 9:00 pm, RFC Errata System <[email-masked]> wrote:

> The following errata report has been submitted for RFC7231,
> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031
> 
> --------------------------------------
> Type: Technical
> Reported by: Anne van Kesteren <[email-masked]>
> 
> Section: 3.1.1.1
> 
> Original Text
> -------------
> media-type = type "/" subtype *( OWS ";" OWS parameter )
> 
> Corrected Text
> --------------
> media-type = type "/" subtype *( OWS ";" OWS [parameter] )
> 
> Notes
> -----
> See the thread at http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0027.html
> 
> Implementations are much more relaxed when it comes to parsing MIME types.
> 
> The above is probably still too strict. E.g. requiring that a parameter contains "=" is something I doubt is actually the case in practice.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7231 (draft-ietf-httpbis-p2-semantics-26)
> --------------------------------------
> Title               : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
> Publication Date    : June 2014
> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jun 2014 13:32:18 +0200

On 2014-06-30 13:00, RFC Errata System wrote:
> ...

I agree that most (if not all) implementations likely can parse 
instances with empty parameters.

But I don't see how this makes the spec incorrect; it just defines 
what's valid (thus MUST be sent).

This is not an erratum but a change request, IMHO.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Jun 2014 14:34:39 -0400

>> See the thread at
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0027.html
>>

> Robed Ones for a ruling on that…

I presume I'm Robed, in this context.  I usually prefer "Exalted"...
"Revered", if you must, but that doesn't have the same ring.  But I'll
take "Robed" for now.

This is absolutely in scope for an errata report.  The question isn't
whether it's appropriate, but whether the change is correct.

Julian says:
> I agree that most (if not all) implementations likely can parse instances
> with empty parameters.
>
> But I don't see how this makes the spec incorrect; it just defines what's
> valid (thus MUST be sent).

To rephrase what Julian's saying: the grammar specifies what we *want*
to be put into these fields.  It's meant to control production, not to
specify or constrain parsing.  I realize that that's a problem (more
below), but it's the case.

And I don't think anyone's trying to say that we *want* things like

   Content-Type: text/plain; ; ;;; charset=iso8859-1;;;;; ; ;;

Assuming that's true (that we don't want to say that those sorts of
things are valid productions, then this report should be rejected.

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?

Barry, Applications AD

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jun 2014 20:50:38 +0200

> Perhaps a separate document?

Certainly lots of work.

The goal would be to unify certain header field syntaxes (is there a 
plural for syntax?).

See, for instance 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes>.

Sadly, this is the kind of work few people want to fund or do.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Jul 2014 13:20:16 +1000

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/

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 1 Jul 2014 08:09:48 +0200

On Tue, Jul 1, 2014 at 5:20 AM, Mark Nottingham <[email-masked]> wrote:
> Anne, is there security impact here?

Rendering

  Content-Type:text/html;

vs showing some kind of error is one of the issues here.

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

Exhaustive parsing rules for HTTP clients would be good. Having them
differ is a big end user transition problem and can slow development
on new clients, such as Servo.

-- 
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Jul 2014 08:45:48 +0200

> vs showing some kind of error is one of the issues here.

True, but what would be a bigger concern is the case where draconic 
error handling results in a *loss* of security (and that's not the case 
here, right?).

> on new clients, such as Servo.

It would be awesome if the people working on Servo would have a look at 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes> and 
try to come up with some kind of library that makes it easier to create 
parsers for the notoriously hard to parse yet similar header fields 
(C-C, WWW-A, C-D, C-T ...)

Best regards, Julian