qBittorrent 5.x login rejected: client requires body "Ok." but qBit now returns HTTP 204 with an empty body #178

Summary

Bookshelf cannot authenticate with current qBittorrent (tested against qBittorrent 5.2.3). Every connection attempt fails with DownloadClientAuthenticationException: Failed to authenticate with qBittorrent, making the client unusable for torrent grabs.

Root cause

src/NzbDrone.Core/Download/Clients/QBittorrent/QBittorrentProxyV2.cs, AuthenticateClient() validates the login response with:

// returns "Fails." on bad login
if (response.Content != "Ok.")
{
    throw new DownloadClientAuthenticationException("Failed to authenticate with qBittorrent.");
}

Older qBittorrent answered a successful /api/v2/auth/login with 200 and the literal body Ok.. qBittorrent 5.x returns 204 No Content with an empty body on success, so the string check always fails even though authentication succeeded (the SID cookie is issued). Verified against the same qBittorrent instance: a curl login returns 204 with a valid SID cookie, and current Radarr connects to it without issue — this fork's client is the only one still requiring the legacy body.

Note: because the client re-runs the login handshake, this cannot be worked around with qBittorrent's auth-subnet whitelist.

Suggested fix

Treat any 2xx login response that is not the explicit failure marker as success, e.g.:

// qBittorrent <5.x returns 200 "Ok." / "Fails."; >=5.x returns 204 with an empty body on success
if (response.Content == "Fails." ||
    (response.StatusCode == HttpStatusCode.OK && response.Content != "Ok."))
{
    throw new DownloadClientAuthenticationException("Failed to authenticate with qBittorrent.");
}

(or simply accept 204/empty-body as success alongside the legacy 200 "Ok."). This matches the behavior current Radarr/Sonarr exhibit against qBittorrent 5.x.