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

Re: [Technical Errata Reported] RFC7231 (4031)

From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 30 Jun 2014 14:34:39 -0400
Message-ID: <CAC4RtVChj8Mv2FxWYXJKpftaxSFxC+Q_U_Dy082+pfMtiHMJXg@mail.gmail.com>
To: Julian Reschke <julian.reschke@greenbytes.de>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Roy Fielding <fielding@gbiv.com>, Pete Resnick <presnick@qti.qualcomm.com>, Mark Nottingham <mnot@mnot.net>, annevk@annevk.nl, HTTP Working Group <ietf-http-wg@w3.org>
>> The following errata report has been submitted for RFC7231,
>> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
>> Type: Technical
>> Reported by: Anne van Kesteren <annevk@annevk.nl>
>>
>> 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.

Mark says:
> 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…

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
Received on Monday, 30 June 2014 18:35:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC