How to reverse-proxy all requests to the same script, without changing (user-visible) URLs

[SimonBranch]

1. Output of caddy version:

pine $ caddy version
v2.6.2
pine $

2. How I run Caddy:

a. System environment:

Arch Linux (systemd, glibc).

b. Command:

$ sudo caddy run

c. Service/unit/compose file:

Not applicable.

d. My complete Caddy config:

localhost

# /tmp/asdf/cgi contains my script, asdf.cgi.
root * /tmp/asdf/cgi
# My FastCGI server is running on port 9000.
reverse_proxy :9000 {
    # Try to rewrite all URLs to use asdf.cgi.
    rewrite /asdf.cgi
    transport fastcgi {
    }
}

# vim:set ts=4 sw=4:

3. The problem I’m having:

My end goal is broader than what the code snippet above tries to accomplish. The goal is to have all FastCGI requests receive an unmodified PATH_INFO and REQUEST_URI, but always set SCRIPT_NAME to asdf.cgi.

I figure that a prerequisite of that is redirecting all requests to asdf.cgi (without worrying about an unmodified PATH_INFO and REQUEST_URI). So that’s what the code snippet tries to do. But the rewrite rule doesn’t seem to accomplish anything — curl https://localhost/fdsa.cgi still tries to retrieve fdsa.cgi, which doesn’t work.

More details: the precise FastCGI server is github/rushsteve1/cgify, which translates between FastCGI and CGI. (I would use a link for that but I’m limited to four. Thanks, discourse :p) The CGI file asdf.cgi contains this:

#!/bin/sh
printf '%s\r\n' "Content-Type: text/plain" ""
env | grep -E 'PATH_INFO|REQUEST_URI|SCRIPT_FILENAME|SCRIPT_NAME'

which simply prints the relevant variables. Also, I don’t know the difference between SCRIPT_NAME and SCRIPT_FILENAME — perhaps I mean the latter.

4. Error messages and/or full log output:

2022/11/26 05:39:02.861 INFO    using adjacent Caddyfile
2022/11/26 05:39:02.862 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2022/11/26 05:39:02.863 INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS   {"server_name": "srv0", "https_port": 443}
2022/11/26 05:39:02.863 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2022/11/26 05:39:02.863 INFO    tls.cache.maintenance   started background certificate maintenance        {"cache": "0xc0006c2fc0"}
2022/11/26 05:39:02.863 INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
2022/11/26 05:39:02.863 INFO    tls     finished cleaning storage units
2022/11/26 05:39:02.882 INFO    pki.ca.local    root certificate is already trusted by system     {"path": "storage:pki/authorities/local/root.crt"}
2022/11/26 05:39:02.882 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2022/11/26 05:39:02.882 INFO    failed to sufficiently increase receive buffer size (was:
208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2022/11/26 05:39:02.882 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2022/11/26 05:39:02.882 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2022/11/26 05:39:02.882 INFO    http    enabling automatic TLS certificate management   {"domains": ["localhost"]}
2022/11/26 05:39:02.882 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [localhost]: no OCSP server specified in certificate", "identifiers": ["localhost"]}
2022/11/26 05:39:02.883 INFO    autosaved config (load with --resume flag)      {"file": "/root/.local/share/caddy/autosave.json"}
2022/11/26 05:39:02.883 INFO    serving initial configuration

5. What I already tried:

• Wrapping the reverse_proxy block in route and handle
• Moving the rewrite rule outside of reverse_proxy
• Looking on Google: “caddy always use same fastcgi script” found …
  • Documentation for php_fastcgi, which I couldn’t figure out how to adapt
  • “Fastcgi_param equivalent”, which was XY-problemed so the answers did not help my question of having a constant SCRIPT_FILENAME
  • “Add support for simple CGI”, which would be nice but doesn’t further my goal of working with vanilla Caddy
  • “PATH_INFO is empty with basic fastcgi Caddyfile”, which seems the most promising but … well, really it demonstrates how complicated the existing machinery is, and the workarounds and changes needed to accomodate that case didn’t seem to help mine.

6. Links to relevant resources:

[francislavoie]

@SimonBranch

a. System environment:

Arch Linux (systemd, glibc).

b. Command:

$ sudo caddy run

c. Service/unit/compose file:

Not applicable.

If you’re on a systemd machine, I strongly recommend running Caddy as a systemd service. See our docs:

Keep Caddy Running - Caddy Documentation

@SimonBranch

But the rewrite rule doesn’t seem to accomplish anything — curl https://localhost/fdsa.cgi still tries to retrieve fdsa.cgi, which doesn’t work.

What’s your evidence for that?

Use the debug global option in Caddy, and you’ll see how the request looks when it gets sent upstream from Caddy’s perspective, in your logs. Add this at the top of your Caddyfile:

{
	debug
}