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.
