Fastcgi_param equivalent

Help
1

1. Caddy version (caddy version):

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

2. How I run Caddy:

On Ubuntu Server, localhost

a. System environment:

20.04

b. Command:

NA

NA

c. Service/unit/compose file:

NA

d. My complete Caddyfile or JSON config:

:8080 {
        root * /var/www/html/wordpress
        php_fastcgi unix//run/php/php7.4-fpm.sock

#       Nginx could load the following URL path
#       fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
#       http://192.168.1.5:8080/wp-content/plugins/p/h.php?service=images&src=http%3A%2F%2F192.168.1.5%3A8080%2Fwp-content%2Fuploads%2F2020%2F11%2F6.jpg

        file_server
}

3. The problem I’m having:

There is a WordPress plugin that is ends with h.php and Caddy basic configuration seem to be short of the ability to execute php file in plugins folder that Nginx fastcgi_param does.

4. Error messages and/or full log output:

NA

5. What I already tried:

Read and search on Github, I don’t see anyone else does it? What is the equivalent code for Caddy?

6. Links to relevant resources:

NA

2

Your problem is on this line. Remove the first /. In Caddy v2, path matching is exact, so you’re telling Caddy to only handle PHP on requests to exactly / and nothing else.

3

Sorry, added them in this post incorrectly, this should be correct.
php_fastcgi unix//run/php/php7.4-fpm.sock

And the issues is still the same as my first post.with fastcgi_param

4

That fastcgi_param's behaviour is already what Caddy does.

You haven’t said what the problem actually is, so I can’t help any further without more information.

5

Without the handle directive, I get error code 404 for http://192.168.1.5:8080/wp-content/plugins/p/h.php in any web browser.

Adding handle directive got return code 200 but file size for http://192.168.1.5:8080/wp-content/plugins/p/h.php are <1KB. Assume to be permission issue?

Caddy using caddy
PHP-FPM using www-data
WordPress using www-data

Update my configuration with addition handle:

Full caddyfile

:8080 { 
        root * /var/www/html/wordpress
        file_server 
        php_fastcgi unix//run/php/php7.4-fpm.sock

        handle /wp-content/plugins/p/* {
                file_server
        }
        handle /wp-content/uploads/* {
                file_server
        }

#       Nginx could load the following path
#       fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
#       http://192.168.1.5:8080/wp-content/plugins/p/h.php?service=images&src=http%3A%2F%2F192.168.1.5%3A8080%2Fwp-content%2Fuploads%2F2020%2F11%2F6.jpg
}
6

Considering that h.php script seems to be meant to serve other files according to the comment you have there, I would assume that calling it without a query would always give you a 404.

But you can find out more by adding this at the top of your Caddyfile, then checking your logs:

{
	debug
}

Assuming you’re running Caddy as a systemd service (because you didn’t specify in the thread template), you can see your logs with journalctl -u caddy --no-pager | less

7

Yup, using caddy with systemd, added the following code to /etc/caddy/Caddyfile and sudo systemctl restart caddy, refresh home page:
{
debug
}

I see the timing log didn’t reflect with latest timing.

8

I don’t understand what you mean. Please share what’s in your logs.

10

Log with parameters in REQUEST_URI

Feb 11 10:05:13 ubuntu caddy[8804]: {"level":"debug","ts":1613037913.960725,"logger":"http.reverse_proxy.transport.fastcgi","msg":"roundtrip","request":{"remote_addr
":"192.168.64.1:57647","proto":"HTTP/1.1","method":"GET","host":"192.168.64.5:8080","uri":"/wp-content/plugins/p/h.php?service=images&src=http%3A%2F%2F1
92.168.64.5%3A8080%2Fwp-content%2Fuploads%2F2020%2F12%2Fsuper-support1.jpg&cacheMarker=1613025607-131780&token=71a3570d16d38a4a","headers":{"X-Forwarded-For":["192.1
68.64.1"],"X-Forwarded-Proto":["http"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 11_3_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.7.4.2 Safari/53
7.36"],"Accept":["image/avif,image/webp,image/apng,image/*,*/*;q=0.8"],"Referer":["http://192.168.64.5:8080/"],"Accept-Encoding":["gzip, deflate"],"Accept-Language":
["en-GB,en-US;q=0.9,en;q=0.8"]}},"dial":"/run/php/php7.4-fpm.sock","env":{"AUTH_TYPE":"","CONTENT_LENGTH":"","CONTENT_TYPE":"","DOCUMENT_ROOT":"/var/www/html/wordpre
ss","DOCUMENT_URI":"/wp-content/plugins/p/h.php","GATEWAY_INTERFACE":"CGI/1.1","HTTP_ACCEPT":"image/avif,image/webp,image/apng,image/*,*/*;q=0.8","HTTP_
ACCEPT_ENCODING":"gzip, deflate","HTTP_ACCEPT_LANGUAGE":"en-GB,en-US;q=0.9,en;q=0.8","HTTP_HOST":"192.168.64.5:8080","HTTP_REFERER":"http://192.168.64.5:8080/","HTTP
_USER_AGENT":"Mozilla/5.0 (Macintosh; Intel Mac OS X 11_3_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.7.4.2 Safari/537.36","HTTP_X_FORWARDED_FOR":"192.168.64
.1","HTTP_X_FORWARDED_PROTO":"http","PATH_INFO":"","QUERY_STRING":"service=images&src=http%3A%2F%2F192.168.64.5%3A8080%2Fwp-content%2Fuploads%2F2020%2F12%2Fsuper-sup
port1.jpg&cacheMarker=1613025607-131780&token=71a3570d16d38a4a","REMOTE_ADDR":"192.168.64.1","REMOTE_HOST":"192.168.64.1","REMOTE_IDENT":"","REMOTE_PORT":"57647","RE
MOTE_USER":"","REQUEST_METHOD":"GET","REQUEST_SCHEME":"http","REQUEST_URI":"/wp-content/plugins/p/h.php?service=images&src=http%3A%2F%2F192.168.64.5%3A8
080%2Fwp-content%2Fuploads%2F2020%2F12%2Fsuper-support1.jpg&cacheMarker=1613025607-131780&token=71a3570d16d38a4a","SCRIPT_FILENAME":"/var/www/html/wordpress/wp-conte
nt/plugins/p/h.php","SCRIPT_NAME":"/wp-content/plugins/p/h.php","SERVER_NAME":"192.168.64.5","SERVER_PORT":"8080","SERVER_PROTOCOL":"HTTP/1
.1","SERVER_SOFTWARE":"Caddy/v2.3.0"}}
11

This looks exactly right. That’s the document root, i.e. root, plus the request path, i.e. /wp-content/plugins/p/h.php.

So the 404 must be served by your wordpress app. Doesn’t look like a problem with Caddy.

12

It’s strange to me, for your reference on the standard Nginx configuration I used:

Nginx configuration added in site-available/default

server {
    listen 8080;
    server_name  localhost;
    root /var/www/html/wordpress;

    location / {
        index  index.html index.htm;
        try_files $uri /index.php;
    }

    # Handles generic .php files
    location ~ \.php$ {
        fastcgi_pass    unix:/run/php/php7.4-fpm.sock;
        include         fastcgi_params;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_intercept_errors on;
    }
}

Caddyfile, I think try_files might work but problem persist

:8080 {
        root * /var/www/html/wordpress
        try_files {path} /index.php
        php_fastcgi unix//run/php/php7.4-fpm.sock
        file_server
}
13

You don’t need this because the php_fastcgi directive has try_files logic built-in:

Please look at your wordpress logs to see what might be going on. I haven’t seen any evidence that the problem is with Caddy.

14

One test I tried to open this link manually by stop and start with nginx and caddy:

http://192.168.64.5:8080/wp-content/plugins/p/h.php?service=images&src=http://192.168.64.5:8080/wp-content/uploads/2020/11/6.png&cacheMarker=1613025607-228843&token=bb51613aa425fe1e

Caddy will redirect to the following link and appear to throw code 404:

http://192.168.64.5:8080/wp-content/plugins/p/h.php

Nginx load (code 200) which is correct while Caddy redirect URL (code 301) which I feel is a bug, I like the team to test out with Phastpress plugin in your instance

15

This topic was automatically closed after 30 days. New replies are no longer allowed.