httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html
Date Mon, 06 Aug 2001 21:18:52 GMT
From: "Joshua Slive" <joshua@slive.ca>
Sent: Monday, August 06, 2001 3:55 PM

> 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.

No, actually DefaultLanguage worked before, and mod_dir and/or mod_negotiation 
then ignored the result :(

> New behaviour: Use the DefaultLanguage both for the response header
> and in the negotiation.

No, the DefaultLanguage defines the file's language.  LanguagePriority defines
the user's language if they didn't pass an Accept-Language header.

> 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?

Yes, my mis-wording, it resolves by LanguagePriority without an Accept-Language.

> > 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.

"Could make" and must are two different meanings.  And yes, this is the project
you and Lars are discussing, no :-?  Easily adapted :)

> > 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.

No.  If they have no Accept-Language, they get LanguagePriority.  If they have
Accept-Languages and none match, then they get the dreaded "no acceptable 
variant, pick one" message :(

> 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.

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 (?)

> Two other notes:
> 
> - This certainly need a CHANGES and upgrading.html note after
> it all shakes out.

Fine, I agree wholeheartedly.  I'll do the CHANGES notes tonight, without introducing
the patch I've suggested above.

> - 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.

As many have pointed out, it hurts one's brain.  I need a vacation :)

Bill



Mime
View raw message