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

Re: [Technical Errata Reported] RFC7231 (4031)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 30 Jun 2014 20:50:38 +0200
Message-ID: <53B1B17E.5070505@gmx.de>
To: Barry Leiba <barryleiba@computer.org>, 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>
On 2014-06-30 20:34, Barry Leiba wrote:
>>> 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:
>>> 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?

Certainly lots of work.

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

See, for instance 

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

Best regards, Julian
Received on Monday, 30 June 2014 18:51:26 UTC

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