Lighttpd webdav behind caddy: MOVE returns status 400

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

as a service. see Install — Caddy Documentation

a. System environment:

  • Debian 11 (bullseye)
  • lighttpd/1.4.59 with dav

d. My complete Caddyfile or JSON config:

dav.myserver.de {
        reverse_proxy localhost:11337
}

(That’s really the complete config. In the whole report, I ran a replace on the domain name and changed it to “myserver”)

3. The problem I’m having:

  • moving/copying files on a webdav server behind caddy fails. (status: 400)
  • moving/copying them without caddy (localhost:11337) works.
  • all other webdav operations are working as intended. (as far as I can tell. See #5 What I already tried)

4. Error messages and/or full log output:

I tried to move rename /foo2 to /foo using cadaver, which resulted in this log:

{
  "level": "debug",
  "ts": 1641727799.5353487,
  "logger": "http.handlers.reverse_proxy",
  "msg": "upstream roundtrip",
  "upstream": "localhost:11337",
  "duration": 0.000654304,
  "request": {
    "remote_addr": "93.232.173.19:54782",
    "proto": "HTTP/1.1",
    "method": "MOVE",
    "host": "dav.myserver.de",
    "uri": "/foo2",
    "headers": {
      "Authorization": [
        "Digest username=\"micha\", realm=\"example\", nonce=\"61dac727:505c297467b213395607a950b27fb1c7\", uri=\"/foo2\", response=\"a1539683c8321ce420f1b66ca7baa95a\", algorithm=\"MD5\", cnonce=\"d9a6d128d0784dd3bb9c20b122e84fb9\", nc=00000004, qop=\"auth\""
      ],
      "User-Agent": [
        "cadaver/0.23.3 neon/0.31.2"
      ],
      "X-Forwarded-For": [
        "93.232.173.19"
      ],
      "X-Forwarded-Proto": [
        "https"
      ],
      "Destination": [
        "https://dav.myserver.de/foo"
      ],
      "Overwrite": [
        "T"
      ]
    },
    "tls": {
      "resumed": false,
      "version": 772,
      "cipher_suite": 4865,
      "proto": "",
      "proto_mutual": true,
      "server_name": "dav.myserver.de"
    }
  },
  "headers": {
    "Content-Type": [
      "text/html"
    ],
    "Content-Length": [
      "345"
    ],
    "Date": [
      "Sun, 09 Jan 2022 11:29:59 GMT"
    ],
    "Server": [
      "lighttpd/1.4.59"
    ]
  },
  "status": 400
}

5. What I already tried:

testing the operations using litmus: (the basic-part works, so i didn’t include that section)

root@myserver:/# litmus http://localhost:11337 micha PASS
-> running `copymove':
 0. init.................. pass
 1. begin................. pass
 2. copy_init............. pass
 3. copy_simple........... pass
 4. copy_overwrite........ pass
 5. copy_nodestcoll....... pass
 6. copy_cleanup.......... pass
 7. copy_coll............. pass
 8. copy_shallow.......... pass
 9. move.................. FAIL (MOVE `/litmus/move' to `/litmus/movedest': 403 Forbidden)
10. move_coll............. pass
11. move_cleanup.......... pass
12. finish................ pass

root@myserver:/# litmus https://dav.myserver.de micha PASS
-> running `copymove':
 0. init.................. pass
 1. begin................. pass
 2. copy_init............. pass
 3. copy_simple........... FAIL (simple resource COPY: 400 Bad Request)
 4. copy_overwrite........ FAIL (COPY-on-existing with 'Overwrite: F' MUST fail with 412 (RFC4918:10.6): 400 Bad Request)
 5. copy_nodestcoll....... WARNING: COPY to non-existant collection '/litmus/nonesuch' gave '400 Bad Request' not 409 (RFC2518:S8.8.5)
    ...................... pass (with 1 warning)
 6. copy_cleanup.......... pass
 7. copy_coll............. FAIL (collection COPY `/litmus/ccsrc/' to `/litmus/ccdest/': 400 Bad Request)
 8. copy_shallow.......... FAIL (MKCOL on `/litmus/ccsrc/': 405 Method Not Allowed)
 9. move.................. FAIL (MOVE `/litmus/move' to `/litmus/movedest': 400 Bad Request)
10. move_coll............. FAIL (collection COPY `/litmus/mvsrc/' to `/litmus/mvdest2/', depth infinity: 400 Bad Request)
11. move_cleanup.......... pass
12. finish................ pass

6. Links to relevant resources:

I compared the lighttpd log, but there is nothing except for the URI and timestamps. And of couse the status code :slight_smile:

this seems to be a lighttpd-issue. using dave works fine…

I’m not sure what to suggest, I’m not seeing much in terms of evidence of a problem with Caddy itself.

Maybe a Lighttpd dev can help you debug what the requests look like when they’re received from Caddy, and compare with a working request without Caddy in front of it.

If you can show that Caddy does something that specifically changes or breaks the request, then we could look into it.

This topic was automatically closed after 30 days. New replies are no longer allowed.