In the documentation here: https://httpd.apache.org/docs/2.4/mod/mod_proxy_ftp.html It says: For a personal login with a specific username, you can embed the user name into the URL, like in: ftp://username@host/myfile ... but when using mod_proxy_ftp through curl and supplying a URL with a username/password (even ftp://anonymous:abc123@server/path), the client will get a "400 BAD REQUEST" response, and the apache error logs will show: ... [core:debug] [pid 3024:tid 140574807373568] protocol.c(895): [client 1.2.3.4:5] AH02422: HTTP Request Line; URI must not contain a username/password Since the error specifically says you can't use a username/password, I assume that is intentional and the documentation is wrong, rather than a bug in mod_proxy_ftp not implementing the feature correctly.
Hi, I don't known mod_proxy_ftp that much, but looking at the code, could you have a try with: HttpProtocolOptions unsafe ?
That did work, but reading the documentation on what that option does: https://httpd.apache.org/docs/2.4/mod/core.html#httpprotocoloptions I don't see any hints there about why it would be required for an ftp URL that looks like it meets the standards for a URL? That option seems to be about allowing non standard (and potentially unsafe) URLs to pass parsing rules? Is basic authentication supplied in the URL now blocked by default for other protocols as well?
Thanks for testing. I think that the relevant part is in RFC 7230 ([1]) cited in the HttpProtocolOptions documentation: > Userinfo (i.e., username and password) are now disallowed in HTTP and > HTTPS URIs, because of security issues related to their transmission > on the wire. (Section 2.7.1) Anyway, IMHO, it should be stated explicitly in the doc, at least where username:password@ is useable. > Is basic authentication supplied in the URL now blocked by default for other > protocols as well? I guess so. [2] is part of the standard URI handling. I'll give it a try with our test framework to confirm. [1]: https://www.rfc-editor.org/rfc/rfc7230#appendix-A.2 [2]: https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/protocol.c?view=markup#l970
This is probably a bigger discussion than this bug report, but it seems like a single on/off switch (HttpProtocolOptions) is not a great way to enable/disable so many options. I can definitely see only wanting to be able to allow usernames/passwords in URLs, without also wanting to have to allow all the other security issues mentioned in RFC 7230. In fact I'd like to be able to enable it just for FTP given that is hardly ever required for http(s) anymore. It's probably worth pointing out that RFC 7230 section 2.7.1 is specifically about http(s) URIs as well and doesn't mention ftp URIs. HTTP has other authentication options available and most sites have moved away from basic auth, so it does make sense to drop the basic auth user/password support from a forward proxy for http(s). FTP however still requires a username and password in most cases (except anonymous). If an FTP URI is being passed through a forward proxy with a username/password it seems more likely that those credentials would be required rather than an attempt to obfuscate the URI. Yes FTP is insecure but it is still used and does require credentials to be passed.