[webkit-dev] Fixing Accept-Language
darin at apple.com
Tue Jun 28 11:32:48 PDT 2005
On Jun 28, 2005, at 11:12 AM, Alexey Proskuryakov wrote:
> 1) Yes, I intended to send the complete list of preferred languages.
From the early days of the Safari project, we've seen problems with
long Accept-Language header fields.
This server failed but started working once we set a maximum length
These servers generated a "Server Error" with older versions of
Safari; I believe they use "Netscape Directory Gateway":
Here's another site that failed:
Any of these sites may have been changed.
If you include German in your list of languages, eBay will not allow
access to certain items, see <http://docs.info.apple.com/article.html?
> 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).
Sure, we should definitely fix this.
> (such as, but not solely, Japanese always getting a huge weight,
> breaking some Adobe pages)
Perhaps what you're referring to here is the fact that Japanese was
always listed as second on the list. As far as I know, it always had
a correct weight. That code was removed because the reason for it was
finally fixed, but then before Tiger shipped we ended up "dumbing
down" the string even more because of the requests above.
> The current one also has some drawbacks (http://
Good point. We probably went too far in "dumbing down" the string --
designing a new string for maximum compatibility will be a challenge.
Implementing it shouldn't be too hard, though.
> 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 didn't know that was the Mozilla default.
I must admit that I have not "tested the Internet" to find all the
sites that work or don't work. But I will say that there are some
sites that work with IE and Safari, but not Mozilla, believe it or not!
> 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.
Those examples above are not necessarily a complete list, but I hope
>> 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.
We'll figure out what to do once that patch is submitted.
I want to be careful to not just put fixes into WebKit because that's
open source. In most cases we don't want to work around broken things
elsewhere in Mac OS X, but instead fix them.
More information about the webkit-dev