Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 51802 invoked by uid 500); 6 Aug 2001 20:54:59 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 51788 invoked from network); 6 Aug 2001 20:54:59 -0000 Date: Mon, 6 Aug 2001 13:55:01 -0700 (PDT) From: Joshua Slive X-X-Sender: To: Subject: Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html In-Reply-To: <274c01c11eb5$221e00b0$93c0b0d0@roweclan.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 150 On Mon, 6 Aug 2001, William A. Rowe, Jr. wrote: > The system will now resolve a multiview properly based on LanguagePriority, > and un-extended names like .html.html will get the DefaultLanguage assigned. To be clear (correct me if I'm wrong): Old behaviour: Use the DefaultLanguage to determine the Content-Language response header, but don't use it in the actual negotiation. New behaviour: Use the DefaultLanguage both for the response header and in the negotiation. If so, I agree that this makes more sense, but it takes away a work-around for the "no acceptable variants" problem (see below). > > You are right that this is a design flaw, both in documentation, and in the > old code (actually, many conflicting bugs, all of which should now be resolved > in Apache 2.0). > > Without an accept-language fault, the server should choose by DefaultLanguage. I don't know what you mean here. The server should be choosing based on the negotiation algorithm, right? > > With an accept-language fault, the server will return no acceptable variant, > with some choices (that aspect needs lots o' work, I'd like to see something > that human beings can grok, such as languages spelled out in their native tounges, > perhaps using utf-8 to endure cross-charset output.) 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. > > The design flaw 'correction' would be to add a directive/option to > enforce the LanguagePriority instead of returning no acceptable > variant. That should not be a difficult patch, if anyone thinks it is > worthwhile. Right. And this is the reason that the .html.html thing was there. We need to avoid confusing the heck out of the thousands of english-speaking people that access the Apache site without "en" in their Accept-Language. As far as I can tell, you just took away the one work-around that could do this, so I think we need to consider a new one. I don't think enforcing LanguagePriority is the right answer, because it means that people who want to are not able to stick to the letter of the content-negotiation specification (by rejecting requests where the client doesn't "accept" anything that the server can provide). I think the right answer (as we discussed the last time this came up) is to have a FallBackLanguage directive for this purpose. Two other notes: - This certainly need a CHANGES and upgrading.html note after it all shakes out. - I'm really impressed you dug through all this. I looked at that code once, and decided I had better things to do with the next decade of my life than figuring out how it works. Joshua.