Android Beta APP Could not connect to WebDAV server

Darkluna · 2026-07-01T15:58:51+00:00

I have encountered the same issue as well. Please provide the following logs for assistance in troubleshooting:

Windows version 10.0-beta.7+982c00aaf is working properly.
The relevant server logs are captured as follows:

```
x.x.x.x | - | 01/Jul/2026:23:26:07 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | - | 01/Jul/2026:23:26:07 +0800 | "webdav.host" | "PROPFIND /dav/zotero/ HTTP/1.1" | 401 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:08 +0800 | "webdav.host" | "PROPFIND /dav/zotero/ HTTP/1.1" | 207 | 190 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:09 +0800 | "webdav.host" | "GET /dav/zotero/nonexistent.prop HTTP/1.1" | 404 | 9 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:10 +0800 | "webdav.host" | "PUT /dav/zotero/zotero-test-file.prop HTTP/1.1" | 201 | 31 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:10 +0800 | "webdav.host" | "GET /dav/zotero/zotero-test-file.prop HTTP/1.1" | 200 | 25 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:11 +0800 | "webdav.host" | "DELETE /dav/zotero/zotero-test-file.prop HTTP/1.1" | 204 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
```

The Android version of Zotero-Beta, Version 1.0.0-247 and 1.0.0-255, is not available.
The server only shows the following log entry.
There are no errors on the server backend.
But it said `Could not connect to WebDAV server` in the APP.

```
x.x.x.x | - | 01/Jul/2026:18:36:26 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Zotero/1.0.0-247 (Android 36)" "x.x.x.x"
x.x.x.x | - | 01/Jul/2026:23:26:37 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Zotero/1.0.0-255 (Android 36)" "x.x.x.x"
```

The log captured in Android debug mode is as follows:

```
(+0000001):[ERROR] WebDavController: checkServerfailed:null
(+0000001):[DEBUG] cf-ray: xxxxxxx-LAX
(+0000000):[DEBUG] server: cloudflare
(+0000000):[DEBUG] report-to:{"group":"cf-nel","max_age":604800,"endpoints":[{"ur!":"https://a.nel.cloudflare.com/report/v4?s=xxxxxxxx"}]}
(+0000000):[DEBUG] cf-cache-status: DYNAMIC
(+0000001):[DEBUG] strict-transport-security:max-age=15768000;
(+0000000):[DEBUG] set-cookie:sl-session=xxxxxxxx;SameSite=None; Secure; Path=/; Max-Age=86400;HttpOnly
(+0000000):[DEBUG] vary: Accept-Encoding
(+0000000):[DEBUG] ms-author-via: DAV
(+0000001):[DEBUG] dav:1, 2
(+0000000):[DEBUG] cache-control: private,no-cache
(+0000000):[DEBUG] allow: OPTIONS, LOCK,PUTMKCOL
(+0000000):[DEBUG] nel:{"report_to":"cf-nel","success_fraction':0.0,"max_age":604800}
(+0000001):[DEBUG] date: Wed, 01 Jul 2026 15:31:11GMT
(+0001792):[DEBUG]<-- 200 https://webdav.host/dav/zotero/(1791ms)
(+0000000):[DEBUG]--> END OPTIONS
(+0000000):[DEBUG] User-Agent: Zotero/1.0.0-255(Android36)
(+0000863):[DEBUG]-> OPTIONS https://webdav.host/dav/zotero/
(+1083566):[INFO] WebDavController: checkServer
```

Additionally, I found that both versions 240 and 246 were still functioning properly on May 27, 2026, at 01:14:18 +0800. No other operations were performed during that time.

dstillman · 2026-07-01T16:00:17+00:00

Can you provide a Debug ID from the app for a Verify Server attempt that produces an error? We always want a Debug ID rather than raw output.

dstillman · 2026-07-01T16:01:24+00:00

The Android version of Zotero-Beta, Version 1.0.0-247 and 1.0.0-255, is not available.

I'm not sure what you mean by this.

dstillman · 2026-07-01T16:02:25+00:00

But that looks like your WebDAV server is fronted by Cloudflare. You should test with a direct connection to your server. We absolutely can't guarantee that a Cloudflare-proxied WebDAV server would work, since Cloudflare has all sorts of complicated bot protection.

Darkluna · 2026-07-01T16:03:08+00:00

Okay, but I can only retrieve the version 255.
Both of my devices are using this version right now.

Debug ID: D722221758

Darkluna · 2026-07-01T16:04:42+00:00

I have tested both direct connections and localhost, and neither of them works, on Android.

dstillman · 2026-07-01T16:05:25+00:00

Then we'd want to see a Debug ID for a direct connection.

dstillman · 2026-07-01T16:10:00+00:00

In particular, this server — or at least the Cloudflare-fronted version of it — isn't advertising support for PROPFIND, which is a basic requirement for WebDAV support. The app isn't reporting the true error properly, but the server response here is broken.

Darkluna · 2026-07-01T16:18:53+00:00

No, It is supported.
You can see that the PC logs I provided show that PROPFIND returns a 401 status code, but the synchronization is working fine.
Other software also works just fine.
I am re-deploying the environment on localhost; please wait a moment.

Darkluna · 2026-07-01T16:30:52+00:00

Without Cloudflare distribution. Debug ID: D1987271945

This is also a PROPFIND request with the HTTP 207 that was just sent out by the PC.
x.x.x.x | Username | 02/Jul/2026:00:32:41 +0800 | "webdav.host" | "PROPFIND /dav/zotero/ HTTP/1.1" | 207 | 35432 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"

dstillman · 2026-07-01T16:48:21+00:00

server: cloudflare

That's still Cloudflare.

Darkluna · 2026-07-01T16:50:06+00:00

It's just the DNS resolution that is handled by Cloudflare;
Cloudflare is not being used for routing.

dstillman · 2026-07-01T16:51:28+00:00

No, it's returning server: cloudflare and other Cloudflare headers. It's literally a Cloudflare server responding to the HTTP request.

Darkluna · 2026-07-01T16:54:45+00:00

The IP address I obtained using `nslookup` is the directed address of my server.
Perhaps it will take some time to synchronize the DNS broadcasts.？

dstillman · 2026-07-01T16:57:00+00:00

If you're going to post here, you're going to have to trust that we know what we're talking about. You provided a debug log that shows Cloudflare servers responding to the app's HTTP request. Perhaps a DNS record is still cached somewhere in the Android network stack — you'll need to figure that out. But we cannot help you until you provide debug output for a direct connection to your WebDAV server.

Re: your edit: it would be a TTL (time-to-live) on the DNS record — there's no "broadcast" — but yes, essentially.

Darkluna · 2026-07-01T17:02:20+00:00

Okay, wait a moment. I'll check my network connection.

Darkluna · 2026-07-01T17:06:20+00:00

New Debug ID: D944720143
There should be the directed address no problems now.

You're right, it's the TTL. This is the new Debug log package.
This time, there should be no Cloudflare relay involved. >-<

dstillman · 2026-07-01T17:20:12+00:00

OK, so the server response is invalid:

content-length: 0
content-encoding: gzip

An empty body can't be a valid gzip stream.

Some clients (apparently the desktop app) could ignore that, and we can make the Android app do so, but if the server is under your control, you should try to fix that.

Darkluna · 2026-07-01T17:27:40+00:00

Yes, I have seen the backend request logs.
However, accessing the subpaths under webdav requires authentication.
Otherwise, it returns a null value.
You can try to directly access the root directory of that site using A segment of routine UA .
I have now unzipped the WAF.

dstillman · 2026-07-01T17:28:39+00:00

Not sure what you're saying here. I explained the problem with your server above. An OPTIONS response body is empty, and the server is claiming that it's gzipped. That's a contradiction.

Darkluna · 2026-07-01T17:35:11+00:00

Okay, I think I understand now. I have turned off the gzip package, but it still doesn’t seem to work correctly?

dstillman · 2026-07-01T19:23:10+00:00

No, still not fixed. Still returning content-encoding: gzip.