127214 - is our Accept-Charset legal?

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Henrik Gemal]

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 ?

Comment 1

[Christopher Hoess (gone)]

This isn't explicitly forbidden by the HTTP spec, but it seems like it could conceivably generate the error 300 (Multiple Choices).

Comment 2

[Darin Fisher]

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.

Comment 3

[Bradley Baetz (:bbaetz)]

Yeah. Isn't this auto generated via teh language prefs? Lets just make * 0.01, I
guess.

Comment 4

[Gagan]

I thought this was auto-generated too. Hmmm... I must be wrong. Bbaetz
suggestion is ok with me.

Comment 5

[Bradley Baetz (:bbaetz)]

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

[Sascha Claus]

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

[Darin Fisher]

-> future, unless someone can demonstrate that this is causing problems for a
real website.

Comment 8

[Katsuhiko Momoi]

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

http://bugzilla.mozilla.org/show_bug.cgi?id=13393

Comment 9

[Adrian Havill]

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.

Comment 10

[Jo Hermans]

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

Comment 11

[Adrian Havill]

Attachment: 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

[Darin Fisher]

-> default owner

Comment 13

[Julian Reschke]

I believe this one can be closed as Accept-Charset isn't sent anymore (see bug 572652)