Feasibility of implementing a new "SAPI" to bridge the Caddy request env and PHP state (superglobals and co.)

[gggeek]

Tldr: would anyone be able to give a rough estimate of the effort needed to implement, and maintain without diverging considerably from mainline, an FP module that would set up the PHP environment (from the received http request, presumably parsed by Caddy into Go data structures) in a slightly unconventional way?

The "unconventional" part being:

1. no need to fill in _GET, _POST, _COOKIES, _FILES, _SERVER['HTTP_*']
2. filling in a PSR-15 ServerRequest instead (this was already discussed in How to use it with the plain psr-15? #1179)
3. take advantage of the fact that in ServerRequest every HTTP header value is an array instead of being a string, as is customary within CGI/FCGI and co.
4. no previous Go experience ;-)

Point 3 is the key here, as what I want to achieve is being able to tell apart the following 2 requests:

GET / HTTP/1.0
HackMe: hello
HackMe: world

and

GET / HTTP/1.0
HackMe: hello, world

Atm, all the webservers/php-sapis I tested transform both of those into $_SERVER['HTTP_HACKME'] = 'hello, world'(*).

But, as the app that I am writing is meant to be a Firewall(**), being able to tell them apart would be useful. As it would nice, but not mandatory, to be able to retrieve the headers with their original casing.

Atm I am eyeing writing a webserver implementation as a self-contained php app (starting from eg. Qbix or AppserverIo), as that allows me to fine-tune the http request parsing to my needs, but it also feels like begging for a mountain of maintenance work, and pining for perf issues.

Of course, if Caddy does not allow access to those http header lines as independent values, this is all moot in the first place...

* = more or less. Some webservers do not strip tabs/spaces around header values as per rfc9110...
** = I know, why on earth did I ever pick this tool for this job?

[dunglas]

Hey, I'm not sure of the estimate, but you can already get all headers with getallheaders(). However, I don't think original casing is preserved, because Go itself normalizes headers. To access raw headers, you'll have to hijack the underlying TCP connection.

Also, please note that this will only works with HTTP/1, because HTTP/2 and HTTP/3 require clients to send full lower case headers before transmission anyway.

[gggeek]

Lol, it did not even occur to me that FP would implement getallheaders :-D

I did a cursory check of the code, and it seems that the Go Net library does indeed use lowercased headers, but it might be preserving duplicate headers without glueing them together...

[gggeek]

PS: it seems that the glueing them together part is actually in FP code, in line 496 of frankenphp.go

So what I am asking for seems to be just a "tiny" addition: basically a go_caddy_request_headers function which does almost the same as go_apache_request_headers, exposed to php, which makes every header value an array...

[gggeek]

PPS: one could instead add a bool $returnArrays arg to frankenphp_response_headers. Benefit: one less function in the frankenphp namespace. Con: not sure everybody would approve of an API which returns either string[] or string[][] based on an input argument...

[dunglas]

Both notations are strictly equivalent according to the RFC

[gggeek]

Well, they are strictly equivalent as long as one plays by the rules.

Take f.e. an http request (or response) with the following headers:

Date: Tue
Date: 29 Oct 2024 16:56:32 GMT

Using the glueing approach, the app. code will see the single header Tue, 29 Oct 2024 16:56:32 GMT - which is a valid date string that follows the rfc format.

Otoh, if there are intermediaries between the User Agent and the Upstream Server, those might take a different approach: validate each header's value in isolation. Resulting in f.e. dropping both headers, keeping only the 1st, keeping only the last (Date being a singleton header).

Of course, the Date header is not security sensitive - at worst it should screw up cache expiration.

But there might be other headers which are both singletons and have security implications - resulting in request/response smuggling...