The default bug view has changed. See this FAQ.

accept language header with q=0.500

RESOLVED FIXED in Firefox 16

Status

()

Core
Networking: HTTP
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: karl155, Assigned: mcmanus)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla17
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16- fixed, firefox17 fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
The Accept-Language header looks a little strange on Nightly.
I did not modify it. After switching to Nightly it automatically changed
from "de-de,de;q=0.8,en-us;q=0.5,en;q=0.3"
to "en-us,en;q=0.500".
Shouldn't it be "en-us,en;q=0.5" or so?
(I don't know the correct one for en-US. But according to Panopticlick this is not the common one.)


GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/16.0 Firefox/16.0a1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.500
Accept-Encoding: gzip, deflate
Connection: keep-alive
(Reporter)

Comment 1

5 years ago
Now Aurora (16.0a2 2012-07-19) shows this behavior too:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/16.0 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.750,en-us;q=0.500,en;q=0.250
Accept-Encoding: gzip, deflate
Connection: keep-alive
Blocks: 572650
This behavior was intentionally changed in bug 672448 to reduce ambiguity in quality values for those who have more than a handful of language preferences.

As of Gecko 16, the Accept-Language header now lists quality values to 3 decimal places. However, this continues to be generated automatically (the same way the 1-decimal place version was), so this will not increase fingerprintability any more than the switch from Aurora 15 to Aurora 16 would (by way of the User-Agent string). Everyone who maintains the default values will still have the same Accept-Language header. It will just differ from the old value.

As this is intended behavior (at least insofar as the code committed in the aforementioned bug is concerned), I'm going to close this as INVALID. If someone has a legitimate problem with this change, though, feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Depends on: 672448
Resolution: --- → INVALID
The trailing zeros don't seem to reduce ambiguity or serve any other purpose. The concern isn't fingerprintability but useless bytes being sent with every HTTP request.
Blocks: 672448
Status: RESOLVED → REOPENED
No longer depends on: 672448
Ever confirmed: true
Resolution: INVALID → ---

Updated

5 years ago
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
(In reply to Dão Gottwald [:dao] from comment #3)
> The trailing zeros don't seem to reduce ambiguity or serve any other
> purpose. The concern isn't fingerprintability but useless bytes being sent
> with every HTTP request.

The way the quality values are calculated, the quality values are evenly spaced between 0 and 1 based on how many language preferences are listed. If the user has a sufficient number of preferences, 1 decimal place will not be enough to disambiguate them, as multiple preferences will be assigned the same quality value. With 3 decimal places (the max allowed by the HTTP spec), this ambiguity does not occur.

Increasing the number of decimal places in the quality values of the Accept-Language header makes that header more useful for those who actually take advantage of it, which is one of things I am aiming to encourage in my implementation of BCP 47 support. This will support the efforts of creating a truly multilingual Open Web.

Of course, the alternative is to exclude trailing zeroes while also allowing up to 3 decimal places, but that code would be inherently more complex. (I'm not sure how complex, though; I imagine it'd still be well within the realm of feasibility.) The only problem, then, is whether there are implementations that do no properly parse the quality values and will list 0.2 as being less than 0.19 (as in, 2 < 19, rather than 19 < 20).
Besides just dropping trailing zeros, another option would be to make the number of decimal places depend on the number of languages.
Sending two insignificant zero digits wastes two bytes per each request, too. I think we shouldn't bloat HTTP requests to cater to bogus server side code that doesn't know how to compare 0.2 and 0.19.

In general, I think Accept-Language has had enough time to show its viability and it has mostly failed, so I think we shouldn't make decisions with the assumption that giving it another decade will make automatic language negotiation work better.
(Assignee)

Comment 7

5 years ago
This is definitely a small waste. Can you just file the servers (if any?) as evang bugs if they can't implement the spec?
(Assignee)

Comment 8

5 years ago
I think we ought to make a change here by largely reverting 672448 before this goes to beta. I propose using up to 3 decimal places, but not padding with insignificant 0's.

bytes matter. and the only beneficiary of the bloat are un-named (hypothetical?) out of spec servers.

biesi?
tracking-firefox16: --- → ?
(In reply to Patrick McManus [:mcmanus] from comment #8)
> I propose using up to 3 decimal places, but not padding
> with insignificant 0's.

Note that doing what I said in comment 5 would let us send e.g. 0.7 instead of 0.75 when the extra 0.05 doesn't serve any purpose.
yeah, let's not add useless zeroes.
(Assignee)

Comment 11

5 years ago
Created attachment 646791 [details] [diff] [review]
backout patch 0

Gordon, I saw that you used checkin-needed to commit this code, so I'll bundle up the backout for you.

we should back it out on 17 and 16, and then you can resumbit (hopefully to 17) a version that doesn't create extra bytes that don't create differentiation. Sorry about the hassle :(

sound ok?
Assignee: nobody → mcmanus
Status: REOPENED → ASSIGNED
Attachment #646791 - Flags: review?(cbiesinger)
We'd consider uplifting, but it's not clear that this needs to be tracked for release given the minimal user impact.
tracking-firefox16: ? → -
Comment on attachment 646791 [details] [diff] [review]
backout patch 0

Review of attachment 646791 [details] [diff] [review]:
-----------------------------------------------------------------

r=biesi assuming this is a straightforward backout. I'm om vacation without a laptop so a reak review is difficult:)
Attachment #646791 - Flags: review?(cbiesinger) → review+
(Assignee)

Comment 14

5 years ago
backout from m-c (ff17)
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c94085402c9
(Assignee)

Comment 15

5 years ago
Comment on attachment 646791 [details] [diff] [review]
backout patch 0

feature not ready for release as-is.. its been backed out of m-c and is now just on FF16.. requesting a? for backing it out of there.
Attachment #646791 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/9c94085402c9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Comment on attachment 646791 [details] [diff] [review]
backout patch 0

backout approved.
Attachment #646791 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 18

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/a5763ac8cbc3
status-firefox16: --- → fixed
status-firefox17: --- → fixed
Patrick, thanks for the assist.

For those wondering, a new patch is up for review in bug 672448. It ensures that the additional decimal places are only used when significant.

For example, if you have four languages in your Accept-Language header, they will get 0.75, 0.5, and 0.25 now, instead of their former 0.8, 0.5, and 0.3. (I hope that's not considered too much of a waste of bytes; if it is, we can discuss it in the other bug.) Two languages (as in default 'en-US') will get the 0.5 value as before.

(In reply to Henri Sivonen (not reading bugmail until 2012-09-17) (:hsivonen) from comment #6)
> Sending two insignificant zero digits wastes two bytes per each request,
> too. I think we shouldn't bloat HTTP requests to cater to bogus server side
> code that doesn't know how to compare 0.2 and 0.19.

I agree that we shouldn't cater to bogus value parsers, and my new patch does not do so.

> In general, I think Accept-Language has had enough time to show its
> viability and it has mostly failed, so I think we shouldn't make decisions
> with the assumption that giving it another decade will make automatic
> language negotiation work better.

This, however, I disagree with right now. Part of the reason that servers have not made much effort to use Accept-Language for language negotiation is because browsers did not make the effort to encourage users to use it. The BCP47 effort that I am spearheading hopes to attempt to do that.

Either way, this is a bigger topic of discussion than what this bug is for, and I don't think it should be involved in any decisions about allowing 3-digit quality values.
You need to log in before you can comment on or make changes to this bug.