Web Server Feature Parity: Apache / Nginx / Caddy vs ephpm

Status of ephpm’s built-in HTTP server against the capabilities PHP developers expect from traditional web servers. This page started life as a gap analysis; most of the gap is now closed. What’s below is a snapshot of where we are, followed by the small remaining backlog.

Current ephpm Capabilities

Comparison vs Apache / Nginx / Caddy

How ephpm stacks up against the traditional servers PHP developers reach for. Everything in the “must-have for production PHP hosting” tier is shipping; the remaining gaps are in the optional / nice-to-have tier.

Production must-haves — all shipping in ephpm

Optional gaps

URL Rewriting in ephpm

The piece every PHP framework actually needs — “if the file doesn’t exist on disk, route to the front controller” — is implemented as server.fallback. It’s the direct equivalent of nginx’s try_files $uri $uri/ /index.php?$query_string;.

[server]
listen = "0.0.0.0:8080"
document_root = "/var/www/html"
index_files = ["index.php", "index.html"]

# Try the literal path, then with a trailing slash, then fall back to
# the front controller. Covers WordPress, Laravel, Drupal, Symfony, and
# effectively any framework that routes through index.php.
fallback = ["{path}", "{path}/", "/index.php?{query}"]

Semantics

• Each entry is checked in order against the filesystem (relative to the document root).
• {path} = the request URI path; {query} = the original query string.
• The last entry is treated as an internal rewrite target (not checked against the filesystem) — so a request to /about that doesn’t resolve to a file gets rewritten to /index.php?… internally.
• Status-code fallbacks are written =404, =403, etc. — handy for “if nothing else matches, return a status.”

Custom error page

Use a fallback entry that points at a static HTML file before the status-code entry:

fallback = ["{path}", "/errors/404.html", "=404"]

When /foo doesn’t resolve and /errors/404.html exists, the HTML is served with a 404 status. If the HTML is missing too, the bare =404 is returned.

Comparison with Apache mod_rewrite

The “not supported” items are deliberately excluded — chain rules, loops, and per-directory .htaccess files are the source of mod_rewrite’s complexity and security pitfalls; nginx and Caddy don’t replicate them either.

Future: regex-based [[server.redirects]] and [[server.rewrites]]

Some users will want explicit regex redirects (e.g. ^/blog/(\d{4})/(\d{2})/(.+)$ → /articles/$3 with a 301) for SEO migrations or non-standard URL schemes. That’s a separate feature on top of fallback — fallback covers framework routing, [[server.redirects]] would cover URL-rewriting-in-the-Apache-sense. Sketch of the eventual config:

[[server.redirects]]
from = "^/blog/(\\d{4})/(\\d{2})/(.+)$"
to = "/articles/$3"
status = 301

[[server.rewrites]]
from = "^/api/v1/(.+)$"
to = "/api.php?route=$1"
condition = { not_file = true }

Neither blocks production PHP hosting today.