You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2001/08/06 21:50:22 UTC
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html
handler.html.html index.html.html server-wide.html.html
On 6 Aug 2001 wrowe@apache.org wrote:
> wrowe 01/08/06 12:37:27
>
> Removed: docs/manual configuring.html.html handler.html.html
> index.html.html server-wide.html.html
> Log:
> These will _not_ be required in 2.0 If they are required today, there is
> still a bug to track down.
>
>
Hmmm... Can you explain a little more how this is supposed to work in 2.0.
As far as I know, the .html.html requirement was a desgin flaw, not a bug.
Have you changed the design? I haven't seen any new directives added.
Joshua.
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Joshua Slive" <jo...@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
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html
handler.html.html index.html.html server-wide.html.html
Posted by Joshua Slive <jo...@slive.ca>.
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. 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 ;-)
Joshua.
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Joshua Slive" <jo...@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
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html
handler.html.html index.html.html server-wide.html.html
Posted by Joshua Slive <jo...@slive.ca>.
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.
Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
The system will now resolve a multiview properly based on LanguagePriority,
and un-extended names like .html.html will get the DefaultLanguage assigned.
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.
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 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.
Bill
----- Original Message -----
From: "Joshua Slive" <jo...@slive.ca>
To: <ne...@apache.org>
Sent: Monday, August 06, 2001 2:50 PM
Subject: Re: cvs commit: httpd-2.0/docs/manual configuring.html.html handler.html.html index.html.html server-wide.html.html
> On 6 Aug 2001 wrowe@apache.org wrote:
>
> > wrowe 01/08/06 12:37:27
> >
> > Removed: docs/manual configuring.html.html handler.html.html
> > index.html.html server-wide.html.html
> > Log:
> > These will _not_ be required in 2.0 If they are required today, there is
> > still a bug to track down.
> >
> >
>
> Hmmm... Can you explain a little more how this is supposed to work in 2.0.
> As far as I know, the .html.html requirement was a desgin flaw, not a bug.
> Have you changed the design? I haven't seen any new directives added.
>
> Joshua.
>
>