You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Marc Slemko <ma...@znep.com> on 2001/08/19 21:00:01 UTC

Re: mod_negotiation/8201: language negotiation rarely works for MSIE or Mozilla (fwd)

The following reply was made to PR mod_negotiation/8201; it has been noted by GNATS.

From: Marc Slemko <ma...@znep.com>
To: Apache bugs database <ap...@apache.org>
Cc:  
Subject: Re: mod_negotiation/8201: language negotiation rarely works for MSIE
 or Mozilla (fwd)
Date: Sun, 19 Aug 2001 11:54:16 -0700 (PDT)

 ---------- Forwarded message ----------
 Date: Sun, 19 Aug 2001 14:39:24 -0400 (EDT)
 From: Greg A. Woods <wo...@weird.com>
 Reply-To: woods-apache.org@weird.com
 To: marc@apache.org
 Cc: apache-bugdb@apache.org
 Subject: Re: mod_negotiation/8201: language negotiation rarely works for
     MSIE or Mozilla
 
 [ On , August 19, 2001 at 17:32:50 (-0000), marc@apache.org wrote: ]
 > Subject: Re: mod_negotiation/8201: language negotiation rarely works for MSIE or Mozilla
 >
 > Synopsis: language negotiation rarely works for MSIE or Mozilla
 > 
 > State-Changed-From-To: open-closed
 > State-Changed-By: marc
 > State-Changed-When: Sun Aug 19 10:32:50 PDT 2001
 > State-Changed-Why:
 > See PR 8194 for a description of the problem and fix; this has already been applied to the CVS tree.
 
 Thanks for the pointer.
 
 I see from that PR, and from the documented algorithm for language
 selection that the real problem is LanguagePriority is not really
 properly documented anywhere (everywhere it is documented is either
 misleading, incorrect, or incomplete), and the limitations of the
 current implementation are not even mentioned in the current release
 notes.
 
 I suspect the correct work-around for almost everyone is to simply never
 use LanguagePriority, but if you do to always be very very careful to
 create its list of languages from exactly the list of current
 "AddLanguage" settings.
 
 This seems especially important since the documented claim that it has
 no effect for correct HTTP/1.1 requests is clearly false.
 
 -- 
 							Greg A. Woods
 
 +1 416 218-0098      VE3TCP      <gw...@acm.org>     <wo...@robohack.ca>
 Planix, Inc. <wo...@planix.com>;   Secrets of the Weird <wo...@weird.com>
 

Re: mod_negotiation/8201: language negotiation rarely works for MSIE or Mozilla (fwd)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Greg A. Woods adds;

>  Thanks for the pointer.
>  
>  I see from that PR, and from the documented algorithm for language
>  selection that the real problem is LanguagePriority is not really
>  properly documented anywhere (everywhere it is documented is either
>  misleading, incorrect, or incomplete), and the limitations of the
>  current implementation are not even mentioned in the current release
>  notes.

Since you added the most recent index.html.* files to your installation,
but apparently used an old httpd.conf file, this entry

  AddLanguage zh-tw .tw                                                                                     

was not updated to;

  AddLanguage zh-tw .zh                                                                                     

Because .zh wasn't recognized, 1.3.x decided that this .zh file was the
best by size, rather than language.  It really has nothing to do with the
LanguagePriority directive, at all.  Had it been recognized, it wasn't in
your LanguagePriority list, so wouldn't be a default choice in any case.

>  I suspect the correct work-around for almost everyone is to simply never
>  use LanguagePriority, but if you do to always be very very careful to
>  create its list of languages from exactly the list of current
>  "AddLanguage" settings.

For 1.3.x, either disable Multiviews, or _assure_ that every filename
extension is in the AddLanguage, AddCharset or AddType list.

>  This seems especially important since the documented claim that it has
>  no effect for correct HTTP/1.1 requests is clearly false.

No, that statement is correct, if the server is configured properly.  That's
true of most Apache directives, misconfiguration (e.g. missing entries) can
lead to unpredicatble results.