[webkit-dev] Fixing Accept-Language

Alexey Proskuryakov ap-carbon at rambler.ru
Tue Jun 28 11:12:10 PDT 2005

On Tue, 28 Jun 2005 10:24:15 -0700 Darin Adler <darin at apple.com> wrote:

>> 2. Add a proper Accept-Language header when creating an  
>> NSURLRequest, thus overriding the default. Downsides: duplicates  
>> work that should be eventually done in NSURLConnection, yet not in  
>> a cross-platform way.
> What is a "proper" Accept-Language header? Older versions of 
> NSURLConnection used to send the complete list of languages specified  in 
>the System Preferences. 

   By proper, I meant:
1) Yes, I intended to send the complete list of preferred languages.
2) Send the same language codes that other browsers do (e.g., Safari sends 
"ru-ru" instead of "ru", and this breaks Outlook Web Access, rdar://4076004).

> This created major compatibility headaches  with many 
>websites, including sites assuming the user was coming from  Germany just 
>because German was one of the listed languages, and web  servers that choked 
>on anything but the simplest . We ended up  dumbing down this header to match 
>more closely what other browsers  send to resolve the compatibility problems.

   I see... I remember that the old implementation had several other issues 
(such as, but not solely, Japanese always getting a huge weight, breaking some 
Adobe pages). The current one also has some drawbacks 
(http://bugzilla.opendarwin.org/show_bug.cgi?id=3510). And since the default 
in Mozilla is two languages (en-us plus en), the servers that only accept the 
simplest form probably wouldn't work with Mozilla/Firefox, too?

   I absolutely agree that it's ultimately a matter of real world compliance. 
Is it possible to disclose some of the examples that led to the aforementioned 
change? That would make regression testing a lot easier.

> If something's broken about this header, I suggest fixing it in 
> NSURLConnection; if there's a need for WebKit to get the header then  we can 
>change NSURLConnection API so that you can query the header  value. Adding 
>code in WebKit to work around the fact that a newer  NSURLConnection is not 
>available yet sounds OK too.

   OK, I'll do the latter if we come to any conclusion as to what the proper 
Accept-Language header should be.

- WBR, Alexey Proskuryakov

More information about the webkit-dev mailing list