Reverse Proxy with Caddy

[ghost]

Hi.

Thanks a lot, again, for this beautiful software.

I'm using Caddy and have struggled to have webdav work correctly with Caddy as Reverse Proxy.

The basic configuration is obviously:

my-domain.tld {
    reverse_proxy localhost:8000
}

It works for the web interface and the client. It also work with Joplin (which I use). But webdav does not work with clients like Nautilus or davfs2.

The solution is to force Caddy to return protocol header "http":

my-domain.tld {
    reverse_proxy /webdav* localhost:8000 {
        header_up X-Forwarded-Proto "http"
    }

    reverse_proxy localhost:8000
}

I don't know if it's related to Caddy or Sync-In. Caddy is supposed to send headers it receives. Could it be Sync-In not sending the appropriate header, simply relying on the protocol header it initially receives from the reverse proxy?

Anyway, with this simple configuration (one may add log directives, obviously), Sync-In seems to be fully working behind Caddy.

Thanks again!

[johaven]

I would be curious to have the full chain of transmitted headers. I had identified an issue with the WebDAV client on Windows, which refused authentication whenever the X-Forwarded-Proto header was present (possibly because it was not the correct scheme).

That’s why, in the NGINX configuration shown in the documentation, I remove this header for the WebDAV route (https://sync-in.com/docs/setup-guide/proxy#nginx-configuration):

map $request_uri $xfp {
    # This header must be null on webdav URI
    # It causes authentication failures with Microsoft-WebDAV-MiniRedir (Windows)
    ~^/webdav(?:/.*)?  "";
    default            $scheme;
}

What we need to determine is whether this is an implementation issue with certain WebDAV clients or something that is not properly handled by Sync-in.

[ghost]

I'm not familiar with NodeJS or Webdav specs. So I asked Claude.ai and it seems that Nautilus or Davfs2 are more strict about respecting Webdav RFC. Claude said webdav server MUST return HTTP header with "http" protocol, no matter what the server receives.
That's what lead me to force Caddy to send "http" to sthe server.

[johaven]

Protocol is different from X-Forwarded-Proto in the headers, and this is not a WebDAV implementation issue but rather a proxying issue and how it is interpreted on the WebDAV client side.

Have you tried Nautilus or davfs2 against the Sync-in demo? If it works, that would mean X-Forwarded-Proto is not required for proper operation, and that Caddy is adding this header to the WebDAV route by default.

[ghost]

I did try with the demo, and it works fine indeed.

[johaven]

It should also work if you set header_up X-Forwarded-Proto "" in your Caddy configuration, right?

[ghost]

It does, yes. I don't understand anything of what it's all about, and I'm sorry for not using appropriate vocabulary (it's far from my area of expertise).

[johaven]

No problem, it's good to share your experience and configuration :)

[Cricx]

I have the same problem (webdav are not working behind caddy as reverse proxy). Many tank for the solution, but since the problem is related to header, it's better to not transfer the header with the directive -header.
Here my conf for sync-in with collabora :

mysite.net {
     reverse_proxy /webdav* 192.168.1.13:18080 {
#     header_up X-Forwarded-Proto "http"
     header_up -X-Forwarded-Proto
     }

    reverse_proxy /browser/* 192.168.1.13:9980

    reverse_proxy /hosting/* 192.168.1.13:9980

    reverse_proxy /cool/* 192.168.1.13:9980

    reverse_proxy 192.168.1.13:18080 {
            header_up Host {host}
            header_up X-Real-IP {remote_host}
            header_up X-Forwarded-Proto {scheme}

            transport http {
                keepalive 32s
                read_timeout 3600s
            }
    }
}