Equivalent of errors stderr in Caddy 2

[AndreKR (André Hänsel)]

1. Output of caddy version:

v2.5.2 h1:eCJdLyEyAGzuQTa5Mh3gETnYWDClo1LjtQm2q9RNZrs=

2. How I run Caddy:

a. System environment:

Windows command prompt

b. Command:

caddy_windows_amd64.exe run

c. Service/unit/compose file:

None

d. My complete Caddy config:

:8080
root * .
file_server
php_fastcgi * 127.0.0.1:9123

3. The problem I’m having:

Here’s a Caddyfile I was using with Caddy 1:

localhost:80
root C:\htdocs
errors stderr
fastcgi / 127.0.0.1:9123 php {
}
on startup "C:\php-8.1.9-nts-Win32-vs16-x64\php-cgi.exe -b 127.0.0.1:9123"

Note the line errors stderr. With this line PHP errors are printed on the console like this:

I want to have the same error output with Caddy 2, but I cannot find the appropriate directive.

4. Error messages and/or full log output:

5. What I already tried:

I’m relatively sure the errors directive does not exist anymore in Caddy 2 but I don’t know what would be its equivalent for Caddy 2.

6. Links to relevant resources:

https://caddy.its-em.ma/v1/docs/errors

[matt (Matt Holt)]

See our upgrade guide. You want handle_errors in v2.

[AndreKR (André Hänsel)]

Sorry, I don’t get the usage of handle_errors. How do I tell it to output to stderr?

[matt (Matt Holt)]

Logs are already written to stderr by default.

For access logging you will need to use the ‘log’ directive. It includes request errors.

[AndreKR (André Hänsel)]

From reading the docs that’s what I thought as well, but effectively it isn’t:

Caddy 1

localhost:80
root C:\htdocs
errors stderr
fastcgi / 127.0.0.1:9123 php {
}
on startup "C:\php-8.1.9-nts-Win32-vs16-x64\php-cgi.exe -b 127.0.0.1:9123"

Error is shown:

Caddy 2

:8080
root * .
file_server
php_fastcgi * 127.0.0.1:9123
log

Error is not shown:

[AndreKR (André Hänsel)]

Uh, wait a second… not only is the error not shown in the log, the request also has a HTTP status code of 200. Maybe those two issues are related? Like this: Caddy for some reason doesn’t know that there was a PHP error, so it doesn’t print to the error log.

The PHP file is just:

<?php
echo 'hello from php';
throw new Exception('something happened');

[francislavoie]

On a hunch, I dug into this a bit. Looks like a bit of code from v1 never made it to v2.

The code would grab the stderr output from the fastcgi connection and wrap it up in a LogError type and pass it up to the caller.

In v2, we don’t do things the same way, because fastcgi is now no longer its own HTTP handler, but a transport under reverse_proxy (the Caddyfile kinda hides that away, but check the adapted JSON config if you want proof, or see the php_fastcgi docs, the Expanded Form section). We can’t just send up an error to reverse_proxy directly because then it would trigger other behaviour making the response look like a 502 Bad Gateway which is untrue.

Anyways, the fastcgi transport in Caddy v2 is missing that wiring to make it possible to display these errors from PHP at all. So we have some work to do there.

But I’m unsure the best way to go about it, we’ll have to have some discussion. For example do we want it to be an opt-in thing to show the errors, there’s pros and cons to that, it could be a “breaking change” or introduce “data leaks” if the error logs contain sensitive information, etc, but the typical user expectation might be that they are logged by default.

FWIW, I replicated it locally (on Linux, not Windows) and I do get status 500 from a simple throw new Exception script, not a 200.

The relevant bit of code from v1 (for my own sake, to follow up later):

caddyserver/caddy/blob/240de5a5dd20caba4560b9463d532dc629aaab4c/caddyhttp/fastcgi/fastcgi.go#L186-L189

[AndreKR (André Hänsel)]

@francislavoie

FWIW, I replicated it locally (on Linux, not Windows) and I do get status 500 from a simple throw new Exception script, not a 200.

That seems to be an issue with PHP, not with Caddy. I took a look at the FastCGI communication in Wireshark.

Test case on Windows:

With a similar setup in an Alpine Docker container: