Mailing List Archive

no acceptable variant mystery
We are using mod_gzip, and php4.1.0. Apache is 1.3.22. The logged errors
(see below) go back long before our recent (minor) version upgrades of
these. The errors only happen occasionally; here's an example from the
error log:

[Sat Dec 22 17:26:06 2001] [error] [client 213.8.226.164]
no acceptable variant: /home/httpd/html/uzixcom/www/index.php

We have a soft link named 'index.php.en' pointing to a non-executable hard
file named 'indexphp'. These entries are among those in our httpd.conf
file:

AddLanguage en .en
DirectoryIndex index.php index.html

The error suggests the index.php.en file isn't being delivered as an
acceptable variant of index.php (which doesn't exist). I just don't
understand why. And why only on occasion.

We've had two reports from people (both using Internet Exploder) who said
they couldn't bring up our page -- but I also see evidence a few others
(browsers unknown) have had the same problem over the past several months.
>>From our end, MSIE appears to have no problem in any version.

Can anyone offer some advice on how to shoot this trouble?

Thanks,

Bud Hovell




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: no acceptable variant mystery [ In reply to ]
> From: Bud Hovell [mailto:bud@uzix.com]
>
> We are using mod_gzip, and php4.1.0. Apache is 1.3.22. The logged errors
> (see below) go back long before our recent (minor) version upgrades of
> these. The errors only happen occasionally; here's an example from the
> error log:
>
> [Sat Dec 22 17:26:06 2001] [error] [client 213.8.226.164]
> no acceptable variant: /home/httpd/html/uzixcom/www/index.php

"No Acceptable variant" means that the server tried to negotiate with the
client to deliver a document that the client finds acceptable, but the
server couldn't find an appropriate document. In this particular case, it
looks like you may have browsers configured without "en" in their
"Accept-Language". Therefore they do not find you index.php.en acceptable
and you get the "no acceptable variant" error. There is a note that
explains language negotation in detail:
http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

If you are not actually offering multiple versions of the document in
multiple languages then you should just avoid negotation entirely.

Joshua.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: no acceptable variant mystery [ In reply to ]
Hi, Joshua ...

> "No Acceptable variant" means that the server tried to negotiate
> with the
> client to deliver a document that the client finds acceptable, but
> the
> server couldn't find an appropriate document. In this particular
> case, it
> looks like you may have browsers configured without "en" in their
> "Accept-Language". Therefore they do not find you index.php.en
> acceptable
> and you get the "no acceptable variant" error. There is a note that
> explains language negotation in detail:
> http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

Very helpful notes -- thanks to Alan for the information, and to you for
providing the pointer and comments above. My understanding of the default
negotiation behavior was in error.

> If you are not actually offering multiple versions of the document in
> multiple languages then you should just avoid negotation entirely.

We anticipate other languages to be offered eventually, so we structured
that way from the beginning. It appears I can add an additional link named
"index.php.php" to avoid this problem -- to be followed by some
confirmation testing.

Again, thanks very much for your help.
---
Bud Hovell




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: no acceptable variant mystery [ In reply to ]
> From: Bud Hovell [mailto:bud@uzix.com]

> We anticipate other languages to be offered eventually, so we structured
> that way from the beginning. It appears I can add an additional
> link named
> "index.php.php" to avoid this problem -- to be followed by some
> confirmation testing.

Yes, that should work. Apache 2.0 will have a configuration directive to
set how fallback works when an acceptable variant can't be found, which
should elimintate the need for the extra file.

Joshua.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: no acceptable variant mystery [ In reply to ]
HI, Joshua ...

> > We anticipate other languages to be offered eventually, so we
> structured
> > that way from the beginning. It appears I can add an additional
> > link named
> > "index.php.php" to avoid this problem -- to be followed by some
> > confirmation testing.
>
> Yes, that should work. Apache 2.0 will have a configuration
> directive to
> set how fallback works when an acceptable variant can't be found,
> which
> should elimintate the need for the extra file.

Thanks very much for the confirmation.
---
Bud Hovell



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org