-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BZ-69203: backport to 2.4.x #470
base: 2.4.x
Are you sure you want to change the base?
Conversation
ylavic
commented
Aug 1, 2024
•
edited
Loading
edited
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not using the result of the below Strip proxy: prefixes for
r->filename
? In case of aRewriterule
I guessr->uri
andr->filename
could 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added 7441bb4 for this, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll create another PR for this because this has nothing to do with BZ-69203 afterall..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #489
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 ? |