I'm not sure about this bug but is the current Accept-Charset legal? Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 can you have two q=0.66 ?
This isn't explicitly forbidden by the HTTP spec, but it seems like it could conceivably generate the error 300 (Multiple Choices).
this is perfectly legal. of course, it seems like there's little point to mention utf-8 if we're going to give it equal priority as '*' hrm... cc'ing gagan and bbaetz for their take on this.
Yeah. Isn't this auto generated via teh language prefs? Lets just make * 0.01, I guess.
I thought this was auto-generated too. Hmmm... I must be wrong. Bbaetz suggestion is ok with me.
See PrepareAcceptCharsets in nsHttpHandler.cpp. utf-8 is also added as a fallback case. It probably should be slightly higher than the other default of *.
You shouldn't give * the same q like utf-8. If a new charset is registered, (older) Mozillas don't support it but accept it with the same q like utf-8. And a better summary like "'*' in Accept-Charset should get lower q= than 'utf-8'" wouldn't be bad.
-> future, unless someone can demonstrate that this is causing problems for a real website.
Target Milestone: --- → Future
Let me CC Adrian who proposed the fix that went into: http://bugzilla.mozilla.org/show_bug.cgi?id=13393
According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14 having two Q values of the same value is perfectly legal. In the case of "Accept", if a "*/*" and/or "something/*" and a "something/something" has the same Q, the most specific (non-starred) has highest precendence. (14.1: "If more than one media range applies to a given type, the most specific reference has precedence.") However, this is ONLY for "Accept" and not "Accept-Charset". http://httpd.apache.org/docs/content-negotiation.html Note that Apache's content-negotiation deviates from RFC2616 in that "the most specific reference" rule is ONLY followed "[i]f the Accept: header contains no q factors at all...." The paragraphs in the "Media Types and Wildcards" section explaining bad wildcard use by clients seem to not be aware that RFC2616 explicitly defines precedence for these cases. The same Q value for Accept-Charset was chosen to emulate the behavior of Navigator 4, which sends the kinda broken/redundant "iso-8859-1,*,utf-8". Comment 1: If you're not getting 300 responses from Netscape Navigator (which has * and utf-8 and iso-8859-1 as the same q", then you probably won't get them from Mozilla's Accept-Charset. Personally, if Nav 4 compat is not a requirement (and it shouldn't, b/c the accept-charset in Nav4 is broken IMO), I'd change it just to encourage Unicode over some legacy enc.
*** Bug 159516 has been marked as a duplicate of this bug. ***
Created attachment 94761 [details] [diff] [review] more compatible with Nav 4 while allowing UTF-8 to be preferred over * Changes the behavior of Accept-Charset for two cases: 1. if the user has only "iso-8859-1" selected as his preferred encoding, the emitted header is almost exactly like Nav 4 (latin-1, utf-8, and * all q=1) 2. if the user has explicitly "utf-8" selected as one of their charsets (the UI only allows one charset, but you can add more via hacking the prefs file), it will have a higher q than * Otherwise, the behavior is exactly like before, with utf-8 and * getting the same q if utf-8 is added by mozilla for semi-nav 4 compatibility.
-> default owner
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---
I believe this one can be closed as Accept-Charset isn't sent anymore (see bug 572652)
Depends on: 572652
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.