https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
Bug ID: 65823
Summary: mod_proxy_http seems to redact the URI
Product: Apache httpd-2
Version: 2.4.52
Hardware: Other
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_http
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
I got a private web application which is connected via VPN to a public web
server running Apache httpd. The OS is FreeBSD 13.0-RELEASE-p6, and Apache has
been installed from the FreeBSD pkg system, i.e. with the default compiler
options.
httpd -v
Server version: Apache/2.4.52 (FreeBSD)
Apache serves as proxy to the Web application. Here come the virtual hosts
settings:
<VirtualHost *:443>
ServerName xyz.example.com:443
ServerAdmin [email protected]
ProxyPass / http://10.11.0.1:80/
ProxyPassReverse / http://10.11.0.1:80/
SSLEngine on
SSLCertificateFile
"/usr/local/etc/letsencrypt/live/example.com/fullchain.pem"
SSLCertificateKeyFile
"/usr/local/etc/letsencrypt/live/example.com/privkey.pem"
</VirtualHost>
10.11.0.1 is the local IP address on the remote side of the VPN tunnel, and the
web application provides WebDAV access to some file hierarchy. Until recently,
the WebDAV shares could be accessed by Windows and Mac clients via said Apache
proxy without any hickups.
I updated the Apache server to v2.4.52, and now Windows clients can’t connect
anymore, while Mac clients and third party Windows software (WinSCP) still can.
Now the debug transcripts of my WebDAV server show clearly, that the Apache
proxy removes trailing slashes from the URI. However, according to
https://datatracker.ietf.org/doc/html/rfc4918, a trailing slash distinguishes a
collection (i.e. a directory of a file system) from ordinary resources (i.e. a
file), and trailing slashes must not be removed for WebDAV functioning
properly.
I found out, that when I run my web application on a non-standard port, e.g.
13939 instead of 80, then the Apache proxy passes the URI without redacting
away trailing slashes, and then Windows WebDAV clients can connect, as before.
I had another issue with an URI which was send to the Apache proxy by ordinary
browsers (Firefox, Chrome, Safari, ...) alike
https://xyz.example.com/|startVA|1|VA|?date=1642726020.032. In case the web
application runs on port 80, this produced a 404, it didn’t even reach my web
app. In case the web app runs on port 13939 then this simply went through
without problems.
I will now run the web app on a non standard port, however, I assume that you
want to consider to revise the rules of the URI sanitizer of the proxy modules.
Best regards
Rolf Jansen
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
