Nzbdrone appears to ignore HTTP 308 redirect

While troubleshooting an issue with Whisparr (, it appears that the HTTP 308 redirect returned by the Whisparr’s API proxy is not properly handled by nzbdrone. It should follow the redirect to https, but it looks like it’s checking the Content-Type header, seeing text/html, and throwing UnexpectedHtmlContentException before following the redirect. I’d expect it to follow the redirects first, then check the Content-Type after the redirects are resolved.

I’ve poked around the source, but I can’t follow the exact sequence of function calls.

Whisparr has nothing to do with sonarr…?

Sonarr replaced NzbDrone years ago.
Are you still running Sonarr v2 (which used nzbdrone for the executables)?

No, I’m using current versions. I’m talking about the code in src/NzbDrone.Common/Http.

Again, Sonarr code has nothing to do with Whisparr…?
Not sure why you believe it does nothing on GitHub indicates it does. The all of the *arrs are completely independent code bases and have no relation to each other.

Just because the code base is similar does not mean they are connected nor related. There is absolutely nothing done in Sonarr’s code that would magically instantly show up in any other *Arr without some human manual intervention

With that said it is an upstream issue in that it can be fixed in Sonarr which then would get pulled downstream to Radarr/Lidarr/Readarr as a new GitHub issue by the bot w/ the commit linked for those to be cherry-picked downstream. GitHub issues for Whisparr and Prowlarr would need to be created manually.

The issue is most likely simply that http 308 is not treated as a redirect which is likely a one or two line fix to add it the list.

But 308 and 307 for that matter are part of the newer RFC

Yes, Radarr, Whisparr, etc. are all forks of Sonarr and inherit the same code. They’ll need to rebase on Sonarr to pull the commits. That’s why I’m posting this as an upstream issue, so all the projects can benefit.

I’m posting this topic because I wanted to confirm it before opening a github issue. I’m not sure where in the source this behavior would be handled, else I’d just make a pull request.

To clarify none of them rebase on any other app. That would be rebase hell given how materially different the apps are

Commits are cherry-picked in

Redirect codes are set here

But a 308 should already be handled in Sonarr v4 (GitHub dev branch) and presumably downstream as well as it’s PermanentRedirect

Reading post-coffee helps

Typically redirects are followed for requests.

The code there doesn’t indicate we handle PermanentRedirect at all.

No need to open a a GHI this is a one line fix…

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.