This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.7.6 step 3 states: "If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding." Questions: what does *all* mean in "set all the charset parameters of that Content-Type"? could you give a concrete example of a case with more than one charset parameter in the single media type value of Content-Type?
IMHO this is a good example of over-specification. Having multiple charset parameters is invalid, specifying the wrong charset is a bug, and relying on case in charset names is a bug. So this specifies behavior for a case of a double client bug + a server bug at the same time. As far as I can tell, no UA except FF has tried to implement this yet; and the implementation in FF has required lots of hacks and layering violations (essentially, the header field parser needs to preserve all kinds of state that otherwise wouldn't be needed). Furthermore, it also doesn't do this for "all" charset parameters. My suggestion would be to drop that silly requirement, and jut clarify that if you specify the charset although XHR will override it, you're on your own.
"text/html;charset=utf-6;charset=utf-9" would be an example. The text should be taken literally, like all text.
I believe this should be left open until you have evidence of at least two implementations doing what the spec asks for.
Oh please. We're not going to open bugs for everything where implementations currently mismatch.
This requirement has been in the spec for years. Last time I checked, only Firefox attempted to implement it, but didn't as specified. I think the logical next step is to actually try to *remove* it from Firefox, and then to simplify the spec.
What do you mean by "it" and what would removing "it" mean? I don't really care that much what we do here, but I disagree that this is over-specification. Multiple charset parameters is a legitimate situation that can come up and implementors need to know what to do.
(In reply to comment #6) > What do you mean by "it" and what would removing "it" mean? I don't really care > that much what we do here, but I disagree that this is over-specification. > Multiple charset parameters is a legitimate situation that can come up and > implementors need to know what to do. things the spec says (last time I checked): a) rewrite Content-Type request header field, because XHR *will* use UTF-8 b) if original charset matched UTF-8, preserve it's exact representation (so don't rewrite "Utf-8" to "UTF-8") c) in addition, do that for all additional charset params So this is an edge case of an edge case of an edge case. Optimally, we can get rid of all of this; just declare that if the sender doesn't specify UTF-8, it's his problem (resulting in an inconsistent request). b) seems to be a workaround for one broken server seen in the past. Maybe it was fixed? c) over-specifies b) for the a broken input. Nobody implements it. Why do you care about this edge case in the first place?
The spec does not do b). It seemed best to replace all charset parameters rather than just the first or last. We could also define either first or last, but I'm not sure how that is better.
(In reply to comment #8) > The spec does not do b). It seemed best to replace all charset parameters > rather than just the first or last. We could also define either first or last, > but I'm not sure how that is better. Well, but UAs do. I haven't seen a UA that does what you want for multiple charset params. It's a garbage parameter.
I don't think all UAs do b) and the specification has to deal with input garbage as we cannot control it. We have to do something.
(In reply to comment #10) > I don't think all UAs do b) and the specification has to deal with input > garbage as we cannot control it. We have to do something. No, you don't "have to do something". It's your choice. Seems this is going nowhere without test cases and comparison of what UAs do, which I'll try to get done as soon time permits.
I'm not going to leave edge cases undefined.
(In reply to comment #12) > I'm not going to leave edge cases undefined. The problem here is that you assume that UAs use a full-blown Content-Type parser here (needed to extract proper type and charset information in the first place), *and* that that parser preserves all the information you want (about duplicated parameters). This is not the case right now, and as far as I can tell. That's why I'm calling this "overspecification". If you absolutely *want* to handle this case, a much much simpler approach is to treat it as error and throw an exception.
I'm not assuming that. I'm just saying I don't want to leave edge cases undefined. We could also make this about the first or last charset parameter, as I've indicated. Throwing an exception instead (where? for what method?) is not at all a simpler solution nor a solution that is going to work.
(In reply to comment #14) > I'm not assuming that. I'm just saying I don't want to leave edge cases > undefined. We could also make this about the first or last charset parameter, > as I've indicated. "If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding." To make this decision, a UA will have to run the field value through a parser, otherwise it will not know about individual parameters. > Throwing an exception instead (where? for what method?) is not at all a simpler > solution nor a solution that is going to work. For setRequestHeader() if possible, otherwise for send(). It is simpler as it doesn't require the UA to have a parser for broken field values. Also, when you claim "is not going to work" it would be awesome if you could explain why.
Because setRequestHeader() would have to get special purpose parsers. That's not how setRequestHeader() works.
(In reply to comment #16) > Because setRequestHeader() would have to get special purpose parsers. That's > not how setRequestHeader() works. "For setRequestHeader() if possible, otherwise for send()."
We cannot start throwing for something we previously did not throw for. Also, I do not see how it's easier as you would still have to parse the header whereas you say a simpler pattern is used (which we could define, I don't mind).
(In reply to comment #18) > We cannot start throwing for something we previously did not throw for. Also, I Why not? > do not see how it's easier as you would still have to parse the header whereas > you say a simpler pattern is used (which we could define, I don't mind). No, if you want to rewrite charset parameters, you need to parse the header. The spec, as written currently, assumes that these parsers are written in a way that a broken field can get parsed, and that information about duplicated parameters is returned. As far as I can tell, this doesn't reflect reality.
Does this part of the spec have any test coverage yet?
Related Mozilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=397234 Test cases: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0955.html