On Thu, Oct 12, 2017 at 10:37:11PM +0300, Reinis Rozitis wrote:
>> This is my current vhost for the webdav access on the nginx rev. proxy:
>[..]
>> If I switch the vhost to listen on port 80 without ssl, everything is
>> fine and files can be renamed or moved via webdav.
>
>If it works on http but not with ssl it might indicate that either this
>configuration part doesn't work as expected:
>
>set $dest $http_destination;
>
>if ($http_destination ~ "^https://(.+)") {
> set $dest http://$1;
>}
>proxy_set_header Destination $dest;
[...]
>> Also every hint how to debug such kind of problems are highly wellcome
>
>One way to debug would be using something like tcpdump either on the nginx or
>apache host to inspect the http headers passed and/or adding them to access
>logs to see what goes wrong.
I've checked the headers with tcpdump now and I think I've found the
problem, but I do not know how to solve it. The Destination header looks
like this:
Destination: http://webdav-ca0609-muenchen.musin.de
This is the address that the users are using from the internet.
But the Destination header should look like this:
Destination: http://webdav.ca0609.muenchen.musin.de
This is the internal address of the server.
Can I put some rewrite roule inside the block where I set the
http_destination? Something like this:
set $dest $http_destination;
>
if ($http_destination ~ "^https://(.+)") {
rewrite ...
set $dest http://...
}
proxy_set_header Destination $dest;
Has someone a hint how the block should look like? Currently I am just
to stupid to find the right rewrite roule and also I have no idea how to
pass the right URI to the $dest variable.
>As far as I understand you are using nginx as an SSL offloader?
Yes. nginx is the reverse proxy in front of 300 servers that offer
different services, one service is webdav. From the internet to the
nginx https is used and to the backends just http. Because we want to
use a wildcard certificate for *.musin.de the adresses reachable from
the internet are a-b-muenchen.musin.de, but the internal adresses are
a.b.muenchen.musin.de. Thats the reason why I need to rewrite the
addresses :-(.
The whole setup is not the best, I know, but its evolved over years and
some things can not be changed easily :-(.
>Is there anything else you do on the proxy?
Yes, I do additional reverse proxying for some other http(s) services
which are running on internal machines, fortunatly all those services
do not need rewriting of addresses and are working fine. I can move all
those services to another machine, if that makes things easier.
>If not maybe it's more easy to use the stream module (
>http://nginx.org/en/docs/stream/ngx_stream_core_module.html ) and ssl offload
>on tcp level rather than deal with the http/headers between (though there is
>a drawback of not getting the real client ip (in a http header) on the
>backend server / hope for PROXY protocol support for backends one day).
Hmm, I'll take a look and think about it, maybe having a seperate
machine and using the streaming module si really the better solution.
Cheers,
Schoepp
--
Christian Schoepplein
Landeshauptstadt Muenchen
Referat fuer Bildung und Sport
Zentrum fuer Informationstechnologie im Bildungsbereich (ZIB)
- Netze und Servermanagement
Postanschrift: Bueroanschrift:
Landeshauptstadt Muenchen Landeshauptstadt Muenchen
Referat fuer Bildung und Sport Referat fuer Bildung und Sport
Postfach Bayerstr. 28 (Raum 5.326)
80313 Muenchen 80335 Muenchen
T: +49 (0)89 233-85906
E: c.schoepplein (at) musin.de
I: http://www.zib.musin.de
Elektronische Kommunikation mit der Landeshauptstadt Muenchen, siehe:
http://www.muenchen.de/ekomm
Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. Pro
Blatt sparen Sie durchschnittlich 15g Holz, 260ml Wasser, 0,05kWh Strom
und 5g CO2.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
