Seafdav broken in 7.1.4 with anonymous requests

I upgraded my test server to 7.1.4 and the webdav function is broken when the application is trying to do anonymous request before sending the request with authentication. The App with the Problem is Keepass2Android.
WinSCP on the other hand is always sending the authentication when accessing the server and it is working without problems. But Keepass2Android is working with Seafile 7.0.5 without any problems, too. Maybe it is a bug with the new wsgidav module in 7.1.4?

Here are the log entries from a request to the 7.1.4 server:

#apache access.log
xx.xx.xx.xx - - [22/Jun/2020:13:00:46 +0200] "GET /seafdav/KeePass/db.kdbx HTTP/1.1" 401 3849 "-" "okhttp/4.2.2"
xx.xx.xx.xx - - [22/Jun/2020:13:00:46 +0200] "GET /seafdav/KeePass/db.kdbx HTTP/1.1" 200 3251826 "-" "okhttp/4.2.2"
xx.xx.xx.xx - - [22/Jun/2020:13:00:48 +0200] "PUT /seafdav/KeePass/db.kdbx HTTP/1.1" 502 3894 "-" "okhttp/4.2.2"

#apache error.log
[Mon Jun 22 13:00:48.480863 2020] [proxy:error] [pid 17833:tid 140092193695488] (104)Connection reset by peer: [client xx.xx.xx.xx:38214] AH01084: pass request body failed to 127.0.0.1:8080 (127.0.0.1)
[Mon Jun 22 13:00:48.481025 2020] [proxy_http:error] [pid 17833:tid 140092193695488] [client xx.xx.xx.xx:38214] AH01097: pass request body failed to 127.0.0.1:8080 (127.0.0.1) from xx.xx.xx.xx ()

#seafile seafdav.log
2020-06-22 13:00:46.124 - <140688345700160> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - (anonymous) - [2020-06-22 11:00:46] "GET /KeePass/db.kdbx" elap=0.000sec -> 401 Not Authorized
2020-06-22 13:00:46.200 - <140688345700160> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - andi@blafasl.de - [2020-06-22 11:00:46] "GET /KeePass/db.kdbx" depth=0, elap=0.039sec -> 200 OK
2020-06-22 13:00:48.478 - <140688345700160> wsgidav.wsgidav_app         INFO    :  127.0.0.1 - (anonymous) - [2020-06-22 11:00:48] "PUT /KeePass/db.kdbx" length=3233358, elap=0.001sec -> 401 Not Authorized

And this is how it looks like on a 7.0.5 server:

#apache access.log
xx.xx.xx.xx - - [22/Jun/2020:12:56:53 +0200] "GET /seafdav/test/test.kdbx HTTP/1.1" 401 3808 "-" "okhttp/4.2.2"
xx.xx.xx.xx - - [22/Jun/2020:12:56:53 +0200] "GET /seafdav/test/test.kdbx HTTP/1.1" 200 2764 "-" "okhttp/4.2.2"
xx.xx.xx.xx - - [22/Jun/2020:12:56:54 +0200] "PUT /seafdav/test/test.kdbx HTTP/1.1" 401 3831 "-" "okhttp/4.2.2"
xx.xx.xx.xx - - [22/Jun/2020:12:56:54 +0200] "PUT /seafdav/test/test.kdbx HTTP/1.1" 204 242 "-" "okhttp/4.2.2"

#apache error.log
nothing

#seafile seafdav.log
nothing

I have already applied the fix for the renaming (MOVE) issue in 7.1.4 as discussed here: Seafdav - MOVE command causing 502

Is there a change to fix the problem on the Seafile side? If you need any further testing or logs, I can provide everything :wink:

1 Like

I did some further testing with some tcpdump capture between the apache reverse proxy and the seafile server.
As far as I can see, the old Seafile Server 7.0.5 behaves as expected with PUT requests without Authentication and continues the TCP stream with the client.
The new Server 7.1.4 terminates the TCP stream with RST flag set after it denied the unathorized PUT request with a 401 message.

Does anyone have an idea how to further check the behavior of the new seafile webdav system? Is there something like a debug log switch?

This could a behavioral change or bug introduced by upstream WsgiDAV. Could you ask on their github issues?

I checked the Github Repo from WsgiDAV and there is a newer Version (3.0.3) available. Maybe you could first upgrade to this?

1 Like

@daniel.pan Any plans or schedule for updaten wsgidav in CE server?

1 Like

We will upgrade the included wsgidav in a later 7.1 version.

Just for Information: This Problem still exist in Version 7.1.5 Community!

We have upgraded the WSGIDAV version. If the issue still persist, you can submit an issue on their github repository. Maybe the author has a better understanding than us.

I found the solution:

I set

“win_accept_anonymous_options”: True

in seahub/thirdpart/wsgidav/default_conf.py and restarted.

Unfortunately still unreliable to unusable with a Win10 client.