On Jul 22, 2009, at 10:36 PM, Darin Fisher wrote:
Firefox and Chrome send very similar A-L headers. Given FF's
marketshare, I'm surprised you observed compat problems with doing
the same. Was that a recent observation? Can you provide more
details about the issues you observed?
I’m not familiar with how Chrome approaches this, but Firefox handles
this by offering a browser setting to explicitly configure a list of
languages for web browsing. Roughly speaking, it’s a direct control of
the Accept-Languages header field. Very few web servers look at this
header field at all.
It should be noted that normally people only have one value (or one
family of values: "en" and "en-US" for example) on the A-L list
Exactly; this is true across browsers. Thus a single value is the
configuration that’s most tested.
Thus the issue is not Firefox market share number that matters, but
rather the vastly smaller number of people using any browser who have
gone to the trouble to put multiple languages in the language list.
What we discovered in 2003 and 2004 was that making a multiple-
language list the norm for people who don’t opt in to it resulted in
many broken websites. Further, almost no websites worked better with a
more complete Accept-Language header field.
We discovered sites that had difficulty with long Accept-Language
header fields containing a large numbers of characters. Here are a few
examples:
- The official Irish Tourist Board site www.ireland.travel.ie did not
load because of the long Accept-Language header.
- A site called termpro.com gave us a “Firewall Security Alert”
because the header was too long. Presumably that’s not the only site
that was affected by this firewall.
- Servers using the Netscape Directory Gateway failed because of the
long header. At the time this included sites such as these:
calendar.gwu.edu
co.stanford.edu
directory.princeton.edu
gun.teipir.gr
ldap.chapman.edu
www.inami.fgov.be
Symptoms were variable and it took us a long time to figure out the
issue was because of long header.
- Another site that had problems with the long list was dirtypictureshow.com
.
Later, we discovered a few other problems. For example, for a while
eBay treated users as if they were browsing from Germany if the German
language appeared anywhere in the list, blocking certain auctions.
Using the languages list from Mac OS X as our default meant that
German would be included for most users.
Once we changed the Safari Accept-Language to be shorter we didn’t get
any more data about the problem, naturally. But I don’t think it is
right to assume that these problematic sites disappeared. It’s not as
if there are a large number of users with any browser that are testing
behavior with a long Accept-Language header field.
I think this boils down to a question of the value of having an
explicit browser preference setting solely to configure the value of
the Accept-Language header field. It seems this is one of those
settings that experts love to tweak, but has little relevance to the
real web. Do we really expect users to go out of their way to
configure such things so they can browse the web? Can’t we just make
the web work for them?
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
