Im running Caddy version (v1.0.4) on Ubuntu 18.04.
Im trying to run a xerochat php webapp from codecanyon Link.
I was migrating my installation manually from VestaCP. I manage to access the frontpage of the app at https://botto.my. However whenever i try to login it give a “405 Method Not Allowed”. I figure its my Caddyfile but im completely clueless in regards the setting of what i should put in there. Im sorry if I didnt provide enough information as I really dont know where to begin with.
Usually I’d say that Caddy wouldn’t be issuing these 405s and it’s probably coming from the backend app.
But I’m actually wondering if those requests are making it to your app at all. You have FastCGI configured for PHP, but those paths that are getting 405s don’t have PHP extensions, so it’s possible they aren’t going to FastCGI at all and Caddy’s static file server is rejecting POSTs to the (possibly nonexistent?) files.
My guess is that there’s a rewrite that needs to take place. Is there example Apache or nginx documentation for how to set up this app?
Hi thank you for taking your time replying, I really appreciate it.
So i end up copying caddyfile from a wordpress setup and it works. i added the rewrite rules but i dont really understand whats going on or why it works. theres a line “if not matching wp-admin path” which is wordpress specific and dosent make any sense to me since its not wp based. i dont even understand why the why php directive is written like that or if its even necessary. this is a total copy paste of steps showed by others. but anyhow i’m glad it worked. would you link me to stuff i can read to understand this stuff. sorry for being a total noob.
You can ditch the the line that reads if {path} not_match ^/wp-admin entirely.
(It’s not even necessary for WordPress - I don’t know why it’s published so widely in example Caddyfiles for WordPress, could be a case of citogenesis!)
What this rewrite does is - if the path doesn’t exist on disk (i.e. /home/central_webhook_callback), Caddy will call /index.php instead. This means the request DOES go to FastCGI instead of being handled by the file server, which naturally turns up no file and doesn’t allow POST requests anyway. Obviously /index.php knows how to deal with these requests.
In effect, this is how PHP apps run with “pretty” URLs instead of having loads of URLs with PHP extensions everywhere. WordPress does it the exact same way, hence the same config working here for you.