But this doesn’t do what I expect it to. I am inexperienced with web servers and trying to learn, so if anything about my attempted conversion strikes you as a fundamental misunderstanding, I’d appreciate extra if you pointed that out. =)
Other than that, I hope this may also serve as a kinda reference as these seem to be slightly nontrivial examples which I couldn’t find a reference in the net for yet.
The php_fastcgi directive has built-in try_files logic which probably is sufficient by default.
Please don’t delete parts of the help template. It’s important that you completely fill it out. We need to understand exactly what isn’t working. Show example requests with curl -v, show your logs, show your entire config, etc.
I’m sorry, I wanted to increase the signal-to-noise in my post. =) I’ve already got the block you posted and the other parts of the setup, I just wasn’t able to directly translate these directives at the time.
However, I managed to do it now. This seems to be a working translation, for anyone looking:
Especially interesting to me: root /foo/* /some/path instead of root /foo/* /some/path/foo. I was looking at the second to last example in root (Caddyfile directive) — Caddy Documentation, but it seems like I misunderstood it.
root /foo/* /some/path will point an incoming your.domain/foo/* to the local /some/path/foo/*!
Yeah, file_server and try_files append the current request path to the defined root, when looking for files on disk. If there’s a doubled-up path segment, then it probably won’t work (unless that was your intent).
This looks strange to me. This’ll match every path, I think. ^ means “assert position at start of line” which will always be true.
Are you only defining a root here? This means root will be unset for any other path, which means try_files won’t work in other paths
This also doesn’t make sense to me. \\ will match the literal character \ in the request path. Why would that ever happen? I don’t think this one will ever match.
This also doesn’t make sense – try_files doesn’t support rewriting the path including a query. You probably want {path}, not {uri}, because {uri} includes the query part.
I don’t see why any of this would be necessary, php_fastcgi should already cover all this.