However, in caddy v2, I cannot even get the main site working, main site responded with not controller found, the log shows uri was rewritten correctly, the request method is right.
Thanks for posting your Caddy v1 config for comparison.
Would you mind filling out the Help template (I’ve copied it below) with all the remaining details - including exact error messages and the v2 config you’ve tried.
1. My Caddy version (caddy -version):
2. How I run Caddy:
Please provide all of the relevant information and DO NOT REDACT anything except passwords/keys. Thank you!
a. System environment:
OS, relevant versions, systemd? docker? etc.
b. Command:
paste command here
c. Service/unit/compose file:
paste full file contents here
d. My complete Caddyfile:
paste Caddyfile here
DO NOT REDACT anything except credentials
3. The problem I’m having:
Please describe the issue thoroughly enough so that anyone can reproduce the exact behavior you’re seeing. Be as specific as possible.
4. Error messages and/or full log output:
Please DO NOT REDACT any information except passwords/keys.
Thanks for the details @WeidiDeng! And thank you for trying the Caddy 2 beta during its pre-release phase.
@Whitestrake I wonder if there’s something a little bit wrong about how we’re setting up the php-fpm environment? It sounds like an MVC framework is complaining that a “controller index” doesn’t exist, maybe a missing file or some wrongly-rewritten URI? (Just throwing out ideas. Too late here for me to be debugging this.)
That’s what it sounds like to me, but I don’t know if it’s a php-fpm setup issue. Both the v1 and v2 PHP setups are pretty spartan on the Caddy side.
@WeidiDeng, I notice that the v2 config has no rewrites in it while the v1 rewrites to try files and then falls back to /index.php{uri}. Is the v2 config you posted the entire config you’re using?
Oh, v2 setup isn’t as spartan as I’d thought, then! Might be relevant; the default doesn’t append {uri} to the end of /index.php, maybe the framework expects/requires that?
Could be. @WeidiDeng can test that: simply replace the php_fastcgi directive with the longer form in the docs (don’t do this normally! the single-line directive is usually preferred!) and then tweak the try_files line and see what happens.
Using the long form, after some testing, I think I find what’s the problem, here is the long form
domain.com:8445 {
tls off
encode gzip
root * /path/main_site
matcher indexFiles {
not {
path */
}
file {
try_files {path}/index.php
}
}
rewrite match:indexFiles {path}/ # No redirect required
# internally rewrite directory URIs to index.php files
try_files {path} {path}/ /index.php/{uri} # Last part is the problem
# proxy any requests for PHP files to backend via FastCGI
matcher phpFiles {
path *.php
}
reverse_proxy match:phpFiles php-fpm:9000 {
transport fastcgi {
split .php
}
}
file_server
}
This time caddy emits error 404 when I request a url that should be processed by php, eg. cmd1, instead of passing /index.php/cmd1 to php, caddy tries to find the file or folder by the name. Also when in the short form, caddy invokes php-fpm, but passed an extra /index.php/ (/index.php/index.php/cmd1), causing the controller not found bug.
I don’t think any changes should be required for the fastcgi config to work, as I used the same fastcgi directive in my Caddyfile when I was testing it.
No, because I’m trying to pass the param to the index.php at the root (/index.php), but can’t do that, path resolution stops at trying to find folders.
Tp5 path is /path/to/tp5, the public path (i.e, the path that is served from the root) is /path/to/tp5/public, but the application is /path/to/tp5/application, which is different from laravel.
After reading the thinkphp document and error page, I found out that I have used thinkphp’s routing module which depends on path_info variable, however, caddy failed to pass that value, causing url resolution failed. That results in thinkphp using fallback index controller which doesn’t exist.
I compared the fastcgi environment variables that Caddy v1 and v2 send over fastcgi, I see no relevant differences.
I went through the thinkphp v5 and v6 framework source code (specifically Request.php, which is where the request is bootstrapped from $_SERVER env vars).
The PATH_INFO var is not needed because there are fallbacks to use REQUEST_URI instead, which should be correctly set. You can probably test this yourself, try dumping $_SERVER in your index.php before the app is booted.
At this point I’m back to my previous answer of “it’s not Caddy, it’s your environment”. There must be something that you didn’t share with us that’s causing your issue.
