WebDAV behind a nginx reverse proxy

Christian Schoepplein c.schoepplein at musin.de
Fri Oct 13 12:47:51 UTC 2017

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.



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: 

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.

More information about the nginx mailing list