BZ-69203: backport to 2.4.x #470
Conversation
ylavic
commented
Aug 1, 2024
•
ylavic
commented
- r1919620
- r1919621
- r1919623
- r1919628
- r1921237
| * If we have a raw control character or a ' ' in nocanon path, | ||
| * correct encoding was missed. | ||
| */ | ||
| if (path == url && *ap_scan_vchar_obstext(path)) { |
There was a problem hiding this comment.
have we intentionally lost failing on spaces here? I guess the original intent was about splitting with CRLF?
There was a problem hiding this comment.
Yes, IIUC that's the issue reported in BZ-69203.
Before 2.4.60+ we didn't call proxy_fcgi_canon() for SetHandler URLs, so SCRIPT_FILENAME was never encoded. Now that we do, this PR applies "nocanon" for SetHandler URLs, and lets spaces through because supposedly they are not harmful in the SCRIPT_FILENAME env var (unlike in the uri-path for an HTTP request..).
modules/proxy/mod_proxy_fcgi.c
Outdated
| if (rconf && rconf->need_dirwalk) { | ||
| char *saved_filename = r->filename; | ||
| r->filename = r->uri; | ||
| ap_directory_walk(r); |
There was a problem hiding this comment.
See https://lists.apache.org/thread/4gw6tsp0xlpdf3l9gtz1jnr5wzycsfg8:
Why not using the result of the below Strip proxy: prefixes for r->filename? In case of a Rewriterule I guess r->uri and r->filename could be fundamentally different path wise.
There was a problem hiding this comment.
Maybe it helps to say a little about this obscure option to try to calculate PATH_INFO. It's meant/doc'ed for ProxyPass/ProxyPassMatch configurations where there was no mapping to FS hence no split off for PATH_INFO.
I don't think any of these proxy-fcgi-pathinfo options are widely used. I guess if r->filename had proxy: prefix stuff in it this was maybe useless since inception hence no users?
OTOH like you say, just peeling it all off as we will already do below would seem to give a better result assuming the user doesn't intend to keep some "original" PATH_INFO.
There was a problem hiding this comment.
Why not using the result of the below Strip proxy: prefixes for
r->filename? In case of aRewriteruleI guessr->uriandr->filenamecould be fundamentally different path wise.
Done in [1] too, but this patch is not ready yet and will probably need more discussions (including with fpm maintainers..). I can take this bit from there though, will do!
[1] https://lists.apache.org/thread/vmz22tv2j8bz7vhw98hy3xwvqyp68cdc
There was a problem hiding this comment.
Added 7441bb4 for this, thanks!
There was a problem hiding this comment.
I'll create another PR for this because this has nothing to do with BZ-69203 afterall..
Before r1918550 (r1918559 in 2.4.60), "SetHandler proxy:..." configurations did not pass through proxy_fixup() hence the proxy_canon_handler hooks, leaving fcgi's SCRIPT_FILENAME environment variable (from r->filename) decoded, or more exactly not re-encoded. We still want to call ap_proxy_canon_url() for "fcgi:" to handle/strip the UDS "unix:" case and check that r->filename is valid and contains no controls, but proxy_fcgi_canon() will not ap_proxy_canonenc_ex() thus re-encode anymore. Note that this will do the same for "ProxyPass fcgi:...", there is no reason that using SetHandler or ProxyPass don't result in the same thing. If an opt in/out makes sense we should probably look at ProxyFCGIBackendType. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1919620 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1919621 13f79535-47bb-0310-9956-ffa450edef68
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1919623 13f79535-47bb-0310-9956-ffa450edef68
…URLs. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1919628 13f79535-47bb-0310-9956-ffa450edef68
Variable from_handler is used once so axe it. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1921237 13f79535-47bb-0310-9956-ffa450edef68
|
What is the ETA for this pull request ? |
