Redirect 301 not working on a local server

Bug report
1

App version: 2.5.2 (1bc02fd84) from F-Droid

Android version: 8.0.0

Device model: ASUS X00RD

Current behaviour: A feed that issues a 301 Redirect should have its URL updated locally.

First occurred: Now

Steps to reproduce:

  1. Write this code in a main.go file and run it with go run main.go 
package main

import "net/http"

func main() {
    http.HandleFunc("/", handle)
    http.ListenAndServe(":44844", nil)
}

func handle(w http.ResponseWriter, r *http.Request) {
    http.Redirect(w, r, "https://corecursive.libsyn.com/feed", 301)
}
  1. Add your local feed LAN URL to AntennaPod manually and subscribe to it.
  2. It will load the feed from corecursive.libsyn.com etc.
  3. Edit the Go file to use a different RSS feed URL in the redirect and restart the server.
  4. Refresh the feed manually on AntennaPod.

The URL will not change in the AntennaPod podcast info, it will keep showing http://localurl:localport, and whenever you change the URL on the server it will keep redirecting to a new feed.

Expected behaviour:
AntennaPod should forget the local LAN URL and assume the URL of the first feed to which it was redirected to as the actual concrete feed URL.

2

A web browser doesn’t have this behavior, it simply follows the URL in the Location header. I’m not sure why AntennaPod should be expected to deviate from this behavior.

3

AntennaPod does update the feed URLs on (permanent, not temporary) redirects to ensure that when the old URL is deleted, users still receive episodes.

Does updating help? We are at 2.6 already, and 2.7 is currently starting to roll out.

To me, this sounds like something is wrong with your go code and not with AntennaPod. I don’t know go and don’t have a development environment set up, so it is hard to confirm. Could you somehow host this on a publicly accessible server?

For testing, I usually use this feed: https://tools.bytehamster.com/podcast/redirect.php. It redirects to a new feed address every 5 seconds (containing a different timestamp in the end of the URL).

1 Like
4

@ByteHamster Very interesting, thanks!

5

Using this URL it did work as expected. Thank you!

But I can’t find anything that might be wrong with my setup. Could it be that my setup is using a local http (not https) URL?

If I learn anything more I’ll report back.

6

I don’t know. Maybe curl -I could help.

7

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