httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Slive <>
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 20:55:01 GMT

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.


View raw message