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: dev@httpd.apache.org > 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. >