Empty Responses for Minimal PHP Setup

1. My Caddy version (caddy version):

2.0 RC1

2. How I run Caddy:

/usr/local/bin/caddy run -config /etc/caddy/Caddyfile2 -watch -adapter caddyfile

a. System environment:

Rasbian Buster on Raspberry Pi 3

d. My complete Caddyfile or JSON config:

server.example.com {

        @pma {
                path /pma/*
        }

        root @pma /srv/pma
        php_fastcgi @pma unix//run/php/php7.2-fpm.sock

}

3. The problem I’m having:

I am currently moving from Caddy V1 to V2. I read the migration guide, however I fail to get a PHP application served with a minimal config file. In the above case I am trying to run phpMyAdmin, from https://server.example.com/pma/. PMA loads about 85 different resources initially, but according to the browser console only index.php is loaded. Everything else is answered by Caddy with a HTTP 200, but without content (content-length is always 0 bytes). I observed the same behaviour when using reverse_proxy to localhost (Gitea, listening on port 3000). I saw several topics on the forum, which seemed somehow similar, but found no configuration which was helpful.

5. What I already tried:

I tried named matchers and direct matching in different flavours, played around with traling slashes and wildcards, but nothing was helpful so far. A simple setup with an index.php containing nothing else than a call to phpinfo() works. I guess it has to do with loading resouces from a root php file. PMA for instance loads https://server.example.com/pma/themes/pmahomme/jquery/jquery-ui.css. This file exists on the server at /srv/pma/themes/pmahomme/jquery/jquery-ui.css, but if I enter the URL in the browser, the CSS is not loaded and displayed. Instead the browser loads index.php and tries to load all resources. I see i.e. a request for https://server.example.com/pma/themes/pmahomme/jquery/themes/pmahomme/jquery/jquery-ui.css. This of course does not exist (wrong URL!), but Caddy again answers with HTTP 200 and a content with 0 bytes.

You’re missing file_server!

Caddy v2 doesn’t enable a static file server by default. I think that’s probably the only thing you’re missing here.

Check out the migration guide:

You can also simplify things a bit by using route to group things together that use the same matcher, and since all you need is a path matcher you can use it inline instead of declaring a matcher block:

server.example.com {
    route /pma/* {
        root * /srv/pma
        php_fastcgi unix//run/php/php7.2-fpm.sock
        file_server
    }
}

Note you still need to specify * as a matcher for root because the next argument begins with / which Caddy would interpret as a path matcher otherwise.

I tried your variant, but the result is the same. Everything is answered with a 200 and no content. I also tried:

root @pma /srv/pma
php_fastcgi @pma unix//run/php/php7.2-fpm.sock
file_server

or

file_server @pma

or

file_server @pma {
  root /srv/pma
}

but that does not make any difference at all.

Can you post your log/stdout output?

Ah, I figured it out - I forgot one part of it:

server.example.com {
    route /pma/* {
        root * /srv/pma
        uri strip_prefix /pma
        php_fastcgi unix//run/php/php7.2-fpm.sock
        file_server
    }
}

Since you’re running your site in a subpath, you need to rewrite the URL to strip /pma since you don’t have /pma inside of /srv/pma on disk. Caddy was looking for a file like /srv/pma/pma/somefile.txt for example.

Alternatively, you could change your root to simply /srv if you have no other directories in there you’re worried about.

1 Like

Thanks a lot, that last change seems to do it!

However, I still don’t understand Caddy’s behaviour here. If it looks for /srv/pma/pma/somefile.txt which does not exist, why all the 200 responses instead of a lot of 404s?

In your situation, this is because of how php_fastcgi is implemented.

If you look at the expanded form, you’ll see try_files {path} {path}/index.php index.php. This tells Caddy to do the following:

  • try to rewrite the URI if the requested file exists on disk (i.e. {root}/{path}/srv/pma/pma/somefile.txt, where root is /srv/pma and {path} is from the URL, /pma/somefile.txt)
  • if it doesn’t, it then checks if the path is a directory and contains index.php within that directory as a fallback
  • if not, as a final fallback, it then rewrites everything else to {root}/index.php which in your case is a file found on disk because you have /srv/pma/index.php.

This approach is ideal for most modern PHP web frameworks because it allows the PHP app to handle path routing internally, and subsequently handle 404s on its own if it can’t handle the route. It seems that phpMyAdmin just happens not to do that and didn’t serve 404s here.

1 Like

I can’t judge about what PHP applications do these days as I am only a PHP user, not a developer.

However, I tried Piwigo with the same approach you described and in general it works. With this setup, it’s doing its job, but some page elements are missing:

server.example.com {
    route /piwigo/* {
        root * /srv/piwigo
        uri strip_prefix /piwigo
        php_fastcgi unix//run/php/php7.2-fpm.sock
        file_server
    }
}

The better configuration, which seems to work entirely, is this:

server.example.com {
    route /piwigo/* {
        root * /srv
        php_fastcgi unix//run/php/php7.2-fpm.sock
        file_server
    }
}

In general, I would recommend running your various sites under subdomains instead of subpaths. Many apps don’t behave well when run inside of a subpath due to using absolute URLs for links and assets.

You could try this instead:

pma.server.example.com {
    root * /srv/pma
    php_fastcgi unix//run/php/php7.2-fpm.sock
    file_server
}

piwigo.server.example.com {
    root * /srv/piwigo
    php_fastcgi unix//run/php/php7.2-fpm.sock
    file_server
}

You can configure your DNS pointing *.server.example.com to the same IP address as server.example.com and Caddy will use SNI (Server Name Identification) to determine which site to serve based on the hostname.

Sure, that’s something I should consider. At least if I hit one of those applications, which do not run nicely with a sub path.

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