Is there any way Apache could do the following?
1. Search for a match in the language and language-locale list
the client provides
2. If no match was found above, strip off the locale and try
again.
3. If there still isn't a match, use the server's default
language.
That way if the server's default is en but has content for en, de, and
fr, and the client specified de-CH, de-AT, and fr-CA, de would be served
instead of defaulting to en. That would seem to be more useful to the
client. As of Apache 2.2.3, that scenario would end up serving en.
Thoughts?
,
Josh.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Joshua Slive
> Sent: Friday, December 08, 2006 2:00 PM
> To: [email protected]
> Subject: IE7 wrecks language negotiation
>
> Following up on a question on the users list, I found this blog entry:
> http://blogs.msdn.com/ie/archive/2006/10/17/accept-language-he
> ader-for-internet-explorer-7.aspx
> which says that IE7 now uses only "language/locale pairs" in
> the Accept-Language header.
>
> They follow this up with:
> "If a given server is only interested in the user's language
> and not the locale, it can ignore the locale portion by
> simply truncating the code at the first dash."
> This tells server to ignore RFC2616 section 14.4 if they wish
> to work with IE7.
>
> The effect of this is that users who specify more than one
> acceptable language in IE7 aren't going to get the one they
> really prefer in many cases when working with HTTP/1.1
> compliant servers (like apache httpd). (If only one language
> is selected, things should work okay because we added a
> work-around for this in 2.0. But it is impossible to
> work-around the problem with multiple languages and still
> follow the RFC.)
>
> It would be possible to add a BrowserMatch-settable variable
> to do the HTTP-breaking recommended by Microsoft, but I don't
> know if it is worth it.
>
> Joshua.
>
