In one deployment of a PHP-based application, Apache's MultiViews
option is being used to hide the .php extension of a request dispatcher script. E.g. a request to
/page/about
...would be handled by
/page.php
...with the trailing part of the request URI available in PATH_INFO
.
Most of the time this works fine, but occasionally results in errors like
[error] [client 86.x.x.x] no acceptable variant: /path/to/document/root/page
My question is: What triggers this error occasionally, and how can I fix the problem?
Short Answer
This error can occur when all the following are simultaneously true:
Your webserver has Multiviews enabled
You are allowing Multiviews to serve PHP files by assigning them an arbitrary type with the
AddType
directive, most likely with a line like this:Your client's browser sends with requests an
Accept
header that does not include*/*
as an acceptable MIME type (this is highly unusual, which is why you see the error only rarely).You have your
MultiviewsMatch
directive set to its default ofNegotiatedOnly
.You can resolve the error by adding the following incantation to your Apache config:
Explanation
Understanding what is going on here requires getting at least a superficial overview of the workings of Apache's
mod_negotiation
and HTTP'sAccept
andAccept-Foo
headers. Prior to hitting the bug described by the OP, I knew nothing about either of these; I hadmod_negotiation
enabled not by deliberate choice but because that's howapt-get
set up Apache for me, and I had enabledMultiViews
without much understanding of the implications of that besides that it would let me leave.php
off the end of my URLs. Your circumstances may be similar or identical.So here are some important fundamentals that I didn't know:
request headers like
Accept
andAccept-Language
let the client specify what MIME types or languages it is acceptable for them to receive the response in, as well as specifying weighted preferences for the acceptable types or languages. (Naturally, these are only useful if the server has, or is capable of generating, different responses based upon these headers.) For example, Chromium sends off the following headers for me whenever I load a page:Apache's
mod_negotiation
lets you store multiple files likemyresource.html.en
,myresource.html.fr
,myresource.pdf.en
andmyresource.pdf.fr
in the same folder and then automatically use the request'sAccept-*
headers to decide which to serve when the client sends a request tomyresource
. There are two ways of doing this. The first is to create a Type Map file in the same folder that explicitly declares the MIME Type and language for each of the available documents. The other is Multiviews.When Multiviews are enabled...
The important thing to note here is that the
Accept
header is still being respected by Apache even with Multiviews enabled; the only difference from the type map approach is that Apache is inferring the MIME types of files from their file extensions rather than through you explicitly declaring it in a type map.The no acceptable variant error is thrown (and a 406 response sent) by Apache when there exist files for the URL it has received, but it's not allowed to serve any of them because their MIME types don't match any of the possibilities provided in the request's
Accept
header. (The same thing can happen if there is, for example, no variant in an acceptable language.) This is compliant with the HTTP spec, which states:You can test this behaviour easily enough. Just create a file called
test.html
containing the string "Hello World" in the webroot of an Apache server with Multiviews enabled and then try to request it with an Accept header that permits HTML responses versus one that doesn't. I demonstrate this here on my local (Ubuntu) machine withcurl
:This brings us to a question that we haven't yet addressed: how does
mod_negotiate
determine the MIME type of a PHP file when deciding whether it can serve it? Since the file is going to be executed, and could spit out anyContent-Type
header it likes, the type isn't known prior to execution.Well, by default, the answer is that MultiViews simply won't serve
.php
files. But chances are that you followed the advice of one of the many, many posts on the internet (I get 4 on the first page if I Google 'php apache multiviews', the top one clearly being the one the OP of this question followed, since he actually commented upon it) advocating getting around this using an AddType directive, probably looking something like this:Huh? Why does this magically cause Apache to be happy to serve
.php
files? Surely browsers aren't includingapplication/x-httpd-php
as one of the types they'll accept in theirAccept
headers?Well, not exactly. But all the major ones do include
*/*
(thus permitting a response of any MIME type - they're using theAccept
header only for expressing preference weighting, not for restricting the types they'll accept.) This causesmod_negotiation
to be willing to select and serve.php
files as long as some MIME type - any at all! - is associated with them.For example, if I just type a URL into the address bar in Chromium or Firefox, the
Accept
header the browser sends is, in the case of Chromium...... and in the case of Firefox:
Both of these headers contain
*/*
as an acceptable content type, and thus permit the server to serve a file of any content type it likes. But some less popular browsers don't accept*/*
- or perhaps only include it for page requests, not when loading the content of a<script>
or<img>
tag that you might also be serving through PHP - and that's where our problem comes from.If you check the user agents of the requests that result in 406 errors, you'll likely see that they're from relatively unusual user agents. When I experienced this error, it was when I had the
src
of an<img>
element pointing to a PHP script that dynamically served images (with the.php
extension omitted from the URL), and I first witnessed it failing for BlackBerry users:To get around this, we need to let
mod_negotiate
serve PHP scripts via some means other than giving them an arbitrary type and then relying upon the browser to send anAccept: */*
header. To do this, we use theMultiviewsMatch
directive to specify that multiviews can serve PHP files regardless of whether they match the request'sAccept
header. The default option isNegotiatedOnly
:But we can get what we want with the
Any
option:To restrict this rule change only to
.php
files, we use a<Files>
directive, like this:And with that tiny (but difficult-to-figure-out) change, we're done!