How should I ascertain whether an HTTP 400, that is reported by DAVx5, every time it polls a specific ICS file, is its fault, or [the] NextCloud [provider]'s?

ℹ️ Support
, ,
1

The basics

  1. Nextcloud Server version:

    30.0.12.2 [1]

  2. Operating system and version:

    AOSP, where adb shell getprop returns:

    [ro.build.version.release]: [15]
[ro.build.display.id]: [FP5.VT2D.C.054.20250814]

  3. Reverse proxy and version:

    ⪆ nginx/1.18.0

  4. Is this the first time you’ve seen this error?

    No. [2]

  5. When did this problem seem to first start?

    2022-05-17. [2:1]

  6. Installation method:

    I utilise a provider: [wim.nl.]tab.digital.

  7. Are you using CloudFlare, mod_security, or similar?

    Not that I see.

Summary of the issue you are facing

≈ versionCode=405040005 of at.bitfire.davdroid reports HTTP 400 ⪆ PT6M subsequent to addition of the account, when accessing a text/calendar file stored in a NextCloud (version: 30.0.12.2) instance’s remote.php/dav/calendars:

I want to report this an issue there, but need to confirm that this isn’t a fault of NextCloud’s first. If I learn that it is, that also saves me needing to transfer the issue.

Steps to replicate it

Merely poll the server, via CalDAV and CardDAV:

Web Browser Log entries

When I visit it now, I merely see:

{"error":"Strict Cookie has not been found in request"}

…and, upon location.reload():

16:26:52.438 GET
https://wim.nl.tab.digital/remote.php/dav/calendars/rokejulianlockhart/3de72895-d345-4ac4-8eec-1418e857ba7e/47b29e62-1c12-497d-936f-55480815b63b.ics
[HTTP/2 412  63ms]

With the headers and cookies removed, the HAR is:

{
  "log": {
    "version": "1.2",
    "creator": {
      "name": "Firefox",
      "version": "143.0.3"
    },
    "browser": {
      "name": "Firefox",
      "version": "143.0.3"
    },
    "pages": [
      {
        "id": "page_1",
        "pageTimings": {
          "onContentLoad": 91,
          "onLoad": 118
        },
        "startedDateTime": "2025-10-08T16:26:52.438+01:00",
        "title": "https://wim.nl.tab.digital/remote.php/dav/calendars/rokejulianlockhart/3de72895-d345-4ac4-8eec-1418e857ba7e/47b29e62-1c12-497d-936f-55480815b63b.ics"
      }
    ],
    "entries": [
      {
        "startedDateTime": "2025-10-08T16:26:52.438+01:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "https://wim.nl.tab.digital/remote.php/dav/calendars/rokejulianlockhart/3de72895-d345-4ac4-8eec-1418e857ba7e/47b29e62-1c12-497d-936f-55480815b63b.ics",
          "httpVersion": "HTTP/2",
          "queryString": [],
          "headersSize": 889
        },
        "response": {
          "status": 412,
          "statusText": "",
          "httpVersion": "HTTP/2",
          "content": {
            "mimeType": "application/vnd.mozilla.json.view",
            "size": 55,
            "encoding": "base64",
            "text": "eyJlcnJvciI6IlN0cmljdCBDb29raWUgaGFzIG5vdCBiZWVuIGZvdW5kIGluIHJlcXVlc3QifQ=="
          },
          "redirectURL": "",
          "headersSize": 1278,
          "bodySize": 1333
        },
        "cache": {},
        "timings": {
          "blocked": 0,
          "dns": 0,
          "connect": 0,
          "ssl": 0,
          "send": 0,
          "wait": 63,
          "receive": 0
        },
        "time": 63,
        "_securityState": "secure",
        "serverIPAddress": "104.21.3.117",
        "connection": "443",
        "pageref": "page_1"
      }
    ]
  }
}
  1. ↩︎

  2. github.com/bitfireAT/davx5-ose/discussions/43#discussioncomment-14312040 ↩︎ ↩︎

2

In the debug zip file from the linked discussion I saw this, which has more details on the 400 reason:

HTTP REQUEST
Request{method=PUT, url=https://wim.nl.tab.digital/remote.php/dav/calendars/rokejulianlockhart/3de72895-d345-4ac4-8eec-1418e857ba7e/95e32c5d-ef67-4611-9c7d-920386eea6de.ics, headers=[If-None-Match:*, User-Agent:DAVx5/4.5.3-ose (dav4jvm; okhttp/5.1.0) Android/15, Accept-Language:en-GB, en;q=0.7, *;q=0.5, Accept-Encoding:br,gzip, Authorization:██]}
[...snip]

HTTP RESPONSE
Response{protocol=h2, code=400, message=, url=https://wim.nl.tab.digital/remote.php/dav/calendars/rokejulianlockhart/3de72895-d345-4ac4-8eec-1418e857ba7e/95e32c5d-ef67-4611-9c7d-920386eea6de.ics}
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\BadRequest</s:exception>
  <s:message>Calendar object with uid already exists in this calendar collection.</s:message>
</d:error>
1 Like
3

@jtr, thank you! That at least correlates this with:

  3. bugs.kde.org/show_bug.cgi?id=406917#c0

  4. bugzilla.mozilla.org/show_bug.cgi?id=1717401#c12 [1]

If so, this might be mitigated with:

However, they stipulate that the current verification mechanism is intra-calendar.

  1. bugzilla.mozilla.org/show_bug.cgi?id=1993382#c0 ↩︎

4

I have filed an issue with DAVx5, because I’ve little reason to believe that this is NextCloud’s fault, and I really do want this diagnosed: