- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 30 Jun 2014 20:50:38 +0200
- 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: 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? 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
Received on Monday, 30 June 2014 18:51:26 UTC