Fix server_scheme leak, HTTPS value validation and X-Forwarded-Host list

[y-ken]

Summary

Three further bug fixes found while reviewing the proxy-header handling (follow-up to #5). No configuration changes are required.

Fixes

server_scheme leaks across requests (same class as the old setport bug)

RPAFsethttps set r->server->server_scheme to https on an https-forwarded request but never reset it. Because server_rec is shared, once any https request was seen the server stayed https, and later plain-HTTP requests produced https:// self-referential URLs (e.g. mod_dir trailing-slash redirects). The scheme is now reset to the original value per request — cfg->orig_scheme was already captured for this but unused.

Forwarded HTTPS value trusted literally

X-Forwarded-HTTPS / X-HTTPS were used as-is, so a value like off still flagged the request as HTTPS. The value is now validated (on / 1 / true / yes / https, case-insensitive); X-Forwarded-Proto is matched case-insensitively too.

Comma-separated X-Forwarded-Host

RPAFsethostname used the raw header value. A list such as a.example, b.example now resolves to the last entry (b.example), the one added by the nearest proxy.

Testing

The CI suite (Apache 2.2 / CentOS 6) gains three regression cases, all passing:

Case	Expectation
https request then a plain request on the same child process	/dir redirect stays http:// (no scheme leak)
X-Forwarded-HTTPS: off	RewriteCond %{HTTPS} is off
X-Forwarded-Host: first.example, second.example	effective Host is second.example

The server_scheme test pins Apache to a single child process (ServerLimit 1/MaxClients 1) so the shared-state leak is observable. README and CHANGES are updated.

🤖 Generated with Claude Code