- From: Barry Leiba <barryleiba@computer.org>
- Date: Mon, 30 Jun 2014 14:34:39 -0400
- 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