bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

is our Accept-Charset legal?




Networking: HTTP
16 years ago
6 years ago


(Reporter: Henrik Gemal, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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).

Comment 2

16 years ago
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

Comment 4

16 years ago
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 *.

Comment 6

16 years ago
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.

Comment 7

16 years ago
-> future, unless someone can demonstrate that this is causing problems for a
real website.
Target Milestone: --- → Future

Comment 8

16 years ago
Let me CC Adrian who proposed the fix that went into:


Comment 9

16 years ago
According to


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".


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.

Comment 10

16 years ago
*** Bug 159516 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
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.

Comment 12

12 years ago
-> default owner
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---

Comment 13

6 years ago
I believe this one can be closed as Accept-Charset isn't sent anymore (see bug 572652)
Depends on: 572652


6 years ago
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.