On Thu, Aug 1, 2024 at 7:57 PM Eric Covener <cove...@gmail.com> wrote: > > On Thu, Aug 1, 2024 at 1:37 PM Yann Ylavic <ylavic....@gmail.com> wrote: > > > > 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). > > Just to recap, FPM doesn't want to find the query it in > SCRIPT_FILENAME, it wants to toss it away because it used to > accidentally end up in there (via mod_rewrite?) But this is where the > mismatch between what we've walked/mapped/authorized and what will be > executed is.
If FPM wants a decoded SCRIPT_FILENAME but no '?' character? Decoding a path with %3f will inevitably give '?', even though it's still the path, why would FPM decode it as a URL and find a query string in there?
