507197 - camino no longer sending the accept-charset header

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[hhaamu]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.11) Gecko/2009060219 Camino/2.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.11) Gecko/2009060219 Camino/2.0b3

Camino 2.0 is no longer sending the accept-charset header. Still works in 1.6

Reproducible: Always

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This has the rather unpleasant side-effect of breaking non-Roman text input/output on sites, such as http://babelfish.altavista.com/

Firefox 3 still sends the correct header.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think I have a fix for this.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Forks

Once upon a time there was global-platform/locale/navigator.properties, which contained "intl.charset.default", and the Mozilla world was happy.  Then came the aviary beasts, which decided global-platform/locale/intl.properties was better (and it also contained "intl.charset.default"), although they never told all.js.  Then a giant amusement decided navigator.properties belonged only to it, so it hoarded navigator.properties away from everyone else.  Then, finally, the chief aviary beast noticed it had never told all.js that global-platform/locale/intl.properties was better, so it did so, and all the aviary beasts rejoiced.

Confusingly, all.js also contains "intl.accept_charsets", which looks like it outputs an accept-charset string, though the pref is in fact unused and has been unused since before at least Mozilla 1.7 (it dates to Mozilla Classic).

Note that, in theory, global-platform/locale/intl.properties should be localizable to allow locales to choose the appropriate default ("first") charset, as well as a locale-specific elipsis character.  In practice, however, no call to this file ever makes it to the StringBundleOverride service, so it's somewhat useless to add this file the the GECKO_STRINGS generation, and I've therefore omitted that from this patch.

Also note that perhaps Necko should be smarter and construct a useful accept-language header when intl.charset.default is empty, but far be it from me to suggest to a network implementation how it should handle unexpected data.

With this patch, however, we now send an accept-charset header again at browserspy.dk.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Don't really care exactly when it regressed, since I was able to figure out the problem/fix just from MXR and about:config.

Comment 5

[Stuart Morgan]

Comment on attachment 391513 [details] [diff] [review]
Forks

sr=smorgan

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on cvs trunk and CAMINO_2_0_BRANCH.