After upgrading to 2.9.0, my web site no longer served /index.html by default, but instead gave a page saying “no input file specified” (a simple 404, I guess). Requesting index.html explicitly worked perfectly.
When I commented out the php_fastcgi directive, the site worked as expected.
This site has some PHP pages (hence the php directive), but it is not a PHP site per se, just individual pages, so there is no index.php at the root level (there are in some picture album directories, though).
Adding the directive “rewrite / /index.html” (as in the config below) restored the expected behaviour - but why was that necessary in 2.9.0 when it wasn’t in 2.8.4?
Paul
2. Error messages and/or full log output:
The only error message is as above, and the corresponding log entry is:
I have just found another related problem: my custom error handler is no longer working. Ignore the fact that the error handler in the config above is broken (it used to work, but I clearly missed a change in syntax in a past update) - I have replaced it with a working error handler.
In 2.9.0 the error handler is not being invoked; the error is being thrown, but handle_errors is being ignored and the default message sent instead. But in the same way as was the reason for starting this thread, removing the php_fastcgi directive makes it work again as expected.
So I can now point to two things which in my system break in 2.9.0, but are restored by removing the php_fastcgi directive - the defaulting to index.html and invoking the custom error handler.
(LATER)
And more - it seems that any (sub)directory access fails to find index.html, and the browse function of file_server also fails (giving a 404). Again php_fastcgi is the key.
I’ve tried your suggestion. Once I had made the links to the handler correctly (including my "to"s and removing the handler placeholder in the reverse_proxy directive), it worked, and resolved all the issues I’ve mentioned while retaining PHP functionality.
That’s got me sorted for now; but I guess something’s wonky in how the php_fastcgi directive is doing things, and obviously it would be nice to be able to use the compact directive.
Because the policy is now first_exist_fallback, index.php is “hardcoded” even if it doesn’t exist. This doesn’t hurt in most cases, except in this one.
I wonder if this is worth it to fix, if the workaround I suggested works.
Further testing showed that this did not fix the index.html and browse in directories other than the root; as well as leaving the handle_errors issue.
When I tried to browse my /images directory, it served the home page. When I tried a subdirectory with an index.html, it served the correct page, but without checking for basic_auth (I hadn’t typed a trailing slash - if I added a trailing slash, the auth dialogue then appeared).
The php_fastcgi option is really geared towards how big PHP web applications using various frameworks have been constructed in the last decade or so. Basically, every request that does not match a pre-existing static file gets sent over to a single entry point PHP router script, usually simply called index.php, which then dynamically decides what to do with it, including generating possible 40x error pages should it decide so.
It sounds like you’d rather have a very traditional setup where only disparate *.php get processed by PHP but have everything else still get handled by the web server.
I wonder if you wouldn’t be better served with a config more like this, replacing anything php related with this snippet:
@phpFiles {
file
path *.php
}
reverse_proxy @phpFiles {
to localhost:9001
to localhost:9002
to localhost:9003
to localhost:9004
to localhost:9005
to localhost:9006
to localhost:9007
to localhost:9008
transport fastcgi {
split .php
}
}
Not at all disputing of course that you’ve bumped into a genuine change in the new version of Caddy making what used to work no longer do so for you. But it is equally true that the php_fastcgi shorthand was always meant for the router script use case, and it seems like a happy accident things still worked out OK for your purposes previously.