You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2022/01/21 00:56:29 UTC
[Bug 65823] New: mod_proxy_http seems to redact the URI
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: bugs@httpd.apache.org
Reporter: apache@cyclaero.com
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 mail@example.com
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
--- Comment #5 from Ruediger Pluem <rp...@apache.org> ---
(In reply to Dr. Rolf Jansen from comment #4)
> Please may I ask a question?
>
> I was under the assumption that the proxy module corrects the Location:
> response header field.
>
> Is that assumption correct?
Yes and no.
It does not do anything specific to slashes, but it does changes if asked to
via the ProxyPassReverse directive. The only thing that you should take care
when using ProxyPassReverse is that both arguments should either end with a
slash or not. You should not have directives where the first argument ends on a
slash and the second does not or vice versa.
With regards to Webdav you should keep in mind that absolute URL's are not only
passed in the Location header but also in the request / response body for
certain methods like MOVE or COPY. This can cause issues if backend and
frontend URL's are different since they are not rewritten on the reverse proxy
like Location headers can be with ProxyPassReverse.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
--- Comment #3 from Ruediger Pluem <rp...@apache.org> ---
You are not the first one who have issues like this with Microsoft WebDav
clients. I thought it had improved in the recent years, but obviously not. And
I say clients, because there are many of them. Which one will be used depends
which software you use. The OS brings one, Office brings one and as far as I
remember even http and https use different ones. Maybe a Windows or Office
update broke your running setup.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
--- Comment #4 from Dr. Rolf Jansen <ap...@cyclaero.com> ---
Please may I ask a question?
I was under the assumption that the proxy module corrects the Location:
response header field.
Is that assumption correct?
--
I still feel a little bit uncomfortable to let my WebDAV server fix the missing
slashes instead of sending a 301 - since I am not sure about all possible
implications (some of which may be security related).
So at the last weekend, I ran some more tests. And when I let my server check
for the presence of the X-Forwarded-Host request header field and based on this
let it correct the Location: field of the 301 response, then the Windows WebDAV
client did work without a problem. I am talking about the client of the base
system (latest Windows 10), which can be used to map network shares.
Another observation which makes everything much more strange is that the
Windows WebDAV client worked, when running my WebDAV server on the port 13939.
That means in this case Windows happily did the correct thing when receiving
the 301 with the local non-proxied URI with slash, like Location:
http://10.11.0.1:13939/rolf/
On the other hand, when my WebDAV server runs on port 80, then the 301 response
is Location: http://10.11.0.1/rolf/ and Windows WebDAV stops working after
receiving this one.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
Dr. Rolf Jansen <ap...@cyclaero.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Dr. Rolf Jansen <ap...@cyclaero.com> ---
I adjusted the loglevel of the Apache proxy and I ran my WebDAV service in
diagnostic mode which logs all the http request/response headers.
With that it became evident, that the trailing slashes became already removed
by the Windows WebDAV client (Microsoft-WebDAV-MiniRedir/10.0.19043).
In this case my WebDAV service responds with a 301, giving back the URI with
the trailing slash in the Location: field. Now for some reasons which only
Microsoft knows, the WebDAV client does the correct thing when the
Location:-URI is not on the standard port, but on 13939 - that is in this case
it tries again with the trailing slash. In case the ProxyPass port is left to
80, the MS WebDAV client stops working after receiving the 301 and bails out —
network error.
I also have no idea on why this setup worked right at the end of last year, and
now it does not anymore.
Anyway, when looking closer on this behaviour, I am confident, that there is
nothing wrong with Apache and its proxy modules. My failure, and please excuse
the false alarm. From my point of view, this issue can be closed.
I did build now my WebDAV service with the directive NOREDIR_FIXSLASH, which
lets the service fix missing slashes and by this does not send a 301 to the
client. This is not ideal, but it is obviously necessary for Microsofts WebDAV.
Sorry again for the inonvenience.
Best regards
Rolf Jansen
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
--- Comment #6 from Dr. Rolf Jansen <ap...@cyclaero.com> ---
(In reply to Ruediger Pluem from comment #5)
> (In reply to Dr. Rolf Jansen from comment #4)
> > Please may I ask a question?
> >
> > I was under the assumption that the proxy module corrects the Location:
> > response header field.
> >
> > Is that assumption correct?
>
> Yes and no.
> It does not do anything specific to slashes, but it does changes if asked to
> via the ProxyPassReverse directive. The only thing that you should take care
> when using ProxyPassReverse is that both arguments should either end with a
> slash or not. You should not have directives where the first argument ends
> on a slash and the second does not or vice versa.
Your response put the notion of "exact match" into my head. Actually the
slashes do match, but the Location: response field of my WebDAV service does
omit the port number in case it is 80, and therefore the host element of the
URI does not match exactly the ProxyPass(Reverse) directives:
ProxyPass / http://10.11.0.1:80/
ProxyPassReverse / http://10.11.0.1:80/
Now, I changed the virtual host settings in Apache:
ProxyPass / http://10.11.0.1/
ProxyPassReverse / http://10.11.0.1/
Then I restarted Apache and the Windows WebDAV client started to work again. I
still have no idea, why it worked at the end of December last year.
> With regards to Webdav you should keep in mind that absolute URL's are not
> only passed in the Location header but also in the request / response body
> for certain methods like MOVE or COPY. This can cause issues if backend and
> frontend URL's are different since they are not rewritten on the reverse
> proxy like Location headers can be with ProxyPassReverse.
Yes, I saw this also when I investigated my present issue. The WebDAV service
in question is completely programmed by me in plain C, and so I am free to use
for the host part of the absolute URI the content of the X-Forwarded-Host
request header field. I need to do some further tests, but it should not be too
difficult.
Thank you so much for your helpful responses. Sorry again for posting something
as a bug, which could be easily resolved by changing the setup.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65823] mod_proxy_http seems to redact the URI
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65823
Ruediger Pluem <rp...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Ruediger Pluem <rp...@apache.org> ---
Can you please increase the loglevel to trace7 and provide the error logs for a
request where the trailing slash gets removed?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org