On Thu, Aug 1, 2024 at 5:51 PM Eric Covener <cove...@gmail.com> wrote: > > But does it leave the splitting problem with decoded %3F?
Yeah but I'm not sure that it's _our_ problem, a "proxy:" r->filename does never contain the query-string in the first place, so any '?' in there (hence in SCRIPT_FILENAME) is part of the actual file path (which we'd encode for proxying any other scheme than fcgi). And the '?' will be in SCRIPT_NAME/PATH_INFO/etc too. If the scripts want the decoded uri-path they have to be consistent and consider that SCRIPT_FILENAME is nothing else than a path (no query-string, which is in ... QUERY_STRING). There is the "proxy-noquery" ->notes which seems to influence whether SCRIPT_FILENAME should include the query-string or not, but that's probably for the "proxy-nocanon" case which uses r->unparsed_uri. And at that "nocanon" point I also think that the users have to keep the pieces.. There is also send_environment() which will strip any query-string (supposedly) from r->filename if it matches r->args (because "Query string in environment only", meaning QUERY_STRING I guess). That's guarded by !FCGI_MAY_BE_FPM though (i.e. never), because FPM seems to have some expectations/workarounds around SCRIPT_FILENAME to address ... who knows. So in this whack-a-mole game I'm afraid we'll have to have an opt-out for every single thing we are supposed to fix :/
