Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <28cd01c11ec9$ea885eb0$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
References: <Pine.WNT.4.33.0108061805580.-1895845-100000@jgcomputer>
Subject: Re: cvs commit: httpd-2.0/docs/manual configuring.html.html
 handler.html.html index.html.html server-wide.html.html
Date: Mon, 6 Aug 2001 17:47:19 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Status: O

From: "Joshua Slive" <joshua@slive.ca>
Sent: Monday, August 06, 2001 5:17 PM


> On Mon, 6 Aug 2001, William A. Rowe, Jr. wrote:
> > > The best thing would be to expose the variants in the CGI/SSI environment
> > > so that the end user could make an appropriate ErrorDocument.  I don't
> > > think the server should get involved in translations.
> >
> > "Could make" and must are two different meanings.  And yes, this is the project
> > you and Lars are discussing, no :-?  Easily adapted :)
> 
> Sure, but at the moment this can't be done because there is no way to
> access the available variant list through CGI/SSI.
> 
> >
> > That's what LanguagePriority already is.  My only suggestion is to use it in
> > lieu of "no acceptable variant" iff there are no acceptable variants and the
> > user had expressed a preference.  By default, this option would be disabled.
> >
> > Maybe call it ForceAcceptableLanguage (?)
> 
> Sure, that sounds fine.
> 
> My main concern is that something be done so that we don't wind up in a
> worse position than before regarding the "no acceptable variant" issue.
> As I understand it, as the code stands now, there is no way to avoid that
> error message.  In my opinion, that makes negotiation useless for "real"
> websites, given the real-world state of browser configurations.  

Stop.  If they configure their browser incorrectly, and omit Accept-Language
(as all too many do, that's a new feature after all!) the server works JUST FINE!

Only if they ask for a language, and can't get it, then they get the error.

> I would therefore consider ForceAcceptableLanguage to be a show-stopper
> requirement, and the improved errordocument capability highly important
> (though not essential).  Of course, I'm not volunteering to write the
> code, so feel free to ignore me ;-)

I trust you are right on this.  Noted.

Bill