Every client here is built with followRedirects(false), because DavResource
requires it — so the DAV calls follow by hand and the two OCS/JSON ones
followed not at all. A Nextcloud that canonicalises host or path with a
301 (apex to www, a trailing slash, a proxy) therefore turned the login
flow's start into a bare failure, its poll into an unexplained
SERVER_ERROR *after* the password was minted and the flow row deleted,
and the app-password revocation into the "attempted, and did nothing"
outcome its own KDoc exists to prevent. All three go through one
follower now, which re-issues the method and body — both routes answer
405 to a GET — bounds the hops, and applies the same downgrade rule
DavResource does.
The home set was resolved against the URL the principal PROPFIND was
aimed at rather than where it landed, though followRedirects rewrites
that location in place and probe() twenty lines above reads it back for
exactly this reason. A permanently moved principal answers a relative
href, which resolved against the old base names a path that 404s — and a
perfectly good account reports that it holds no calendars.
And a failing multiget batch discarded every batch before it: the
runCatching wrapped the whole loop rather than one request, so a 500 on
batch seven of ten threw away two hundred parsed resources and answered
Result.failure, and the collection re-downloaded everything next run. It
now keeps what it has and lets the unasked hrefs fall out as missing,
which the engine already counts rather than acting on. A run that got
nothing at all still fails.
makiolaj
1a0041f8fa