From 1da82b3a7f9342490e5540d4cc8e77085eb30a97 Mon Sep 17 00:00:00 2001 From: Crinlorite Date: Sun, 23 Aug 2026 15:31:01 +0200 Subject: [PATCH] docs(cloud-sync): document WebDAV HTTP -1 failures caused by connection reuse Adds a troubleshooting entry for the case where Cloud Sync reports "finished with failures" while every file actually reaches the server. The frontend logs HTTP -1 for some transfers because the response could not be read, while the server's access log shows the same requests completing with 201/204 (and 405 for MKCOL on an existing collection). This happens when a pooled connection is reused after the server closed it; Apache's default KeepAliveTimeout is 5 seconds. Documents the server-side workaround (BrowserMatch nokeepalive for the libretro user agent) and notes that a failed manifest upload leaves the local manifest stale, which surfaces as spurious conflicts on the next sync. --- docs/guides/retroarch-cloud-sync.md | 30 +++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/guides/retroarch-cloud-sync.md b/docs/guides/retroarch-cloud-sync.md index 5d7ec7f7aa..46811e9509 100644 --- a/docs/guides/retroarch-cloud-sync.md +++ b/docs/guides/retroarch-cloud-sync.md @@ -208,6 +208,36 @@ Cloud Sync logs detailed information prefixed with `[CloudSync]`. - Always let sync complete before closing RetroArch - Check logs to identify which files are conflicting +**WebDAV: "finished with failures" although the files are on the server** + +If the log shows `HTTP -1` for some transfers: + +``` +[WARN] [webdav] Failed: manifest.server: HTTP -1 +[ERROR] [CloudSync] Uploading updated manifest failed. +``` + +check the server's access log for those same requests. If the server recorded +them as `201`/`204` (and `405` for `MKCOL` on an existing collection), the +transfers did succeed and the failure is in reading the response, not in the +upload. + +This happens when the connection is reused after the server has already closed +it — Apache's default `KeepAliveTimeout` is 5 seconds, and a sync with many +files easily spans that. On Apache, telling the server not to keep connections +alive for this client avoids it: + +```apache +BrowserMatch "libretro" nokeepalive downgrade-1.0 force-response-1.0 +``` + +This only affects RetroArch's user agent; other clients keep HTTP/1.1 with +keep-alive. + +Note that a failed manifest upload also leaves the local manifest stale, which +shows up as spurious `Conflicting change of ...` on the following sync, so +fixing this usually clears those too. + **iCloud Drive: "Can't see files in Files.app"** This is intentional. Files are stored in a private app container to protect sync integrity. Your data is syncing correctly even though it's not visible in Files.app.