Vienna replaces the links to certain feeds reproducibly in 3.8-beta.2

[nathanlesage]

First of all, thank you so much for your work on this feed reader. It is a blessing in times of SaaS flooding the feed reader business.

Describe the bug

I have a few dozen feeds, two of which expose the behavior mentioned in the title. These are specifically the feeds to the Annual Review of Sociology and Annual Review of Political Sciences:

https://www.annualreviews.org/action/showFeed?ui=45mu4&mi=3fndc3&ai=t0&jc=soc&type=etoc&feed=atom

https://www.annualreviews.org/action/showFeed?ui=45mu4&mi=3fndc3&ai=rx&jc=polisci&type=etoc&feed=atom

These feeds contain a lot of GET params, but work perfectly fine with Vienna.

However, I have noticed that after a certain period (mostly days, sometimes weeks), both these feeds suddenly display a warning icon and the feed URL has been replaced with Annual Review's maintenance page (here is a link).

I do not see why Vienna would override the URL to a feed with a URL that does not even point towards a correct feed. This is especially frustrating because I have to notice this warning icon, then go to the ARS/ARPS pages and exchange the link to the feed once again; sometimes every other day.

To Reproduce

1. Subscribe to the two feeds of ARS and/or ARPS (either should expose the behavior)
2. Wait a few days. At some point the feeds will feature a yellow warning triangle. If you then right-click the feed and select Edit …, you will see that the feed URL has been quietly replaced with the maintenance page of Annual Reviews.

Please complete the following information:

• Vienna version: 3.8.0-beta.2
• OS version: macOS 12.2.1

Additional information:

Currently, I think that it is an interaction between Vienna and the Annual reviews website. I suspect that they will put their page into maintenance mode regularly to update something, and during that time, if Vienna refreshes the feed, it will receive a 3xx HTTP status code, forwarding to the maintenance page. Something inside Vienna (at least that's my theory) then interprets this as an "Aha, the feed has been permanently moved!" and replaces the feed link without further checking.

It would be great to have either of the following alternatives:

• Simply never replace a feed link, even if it stops working, and let the user sort this out.
• Always ask before replacing the feed URL
• Add an option in the preferences that lets users choose if they want to replace the URL automatically, or not.

Thank you very much again, and thank you for considering.

[Eitot]

Vienna indeed updates feed URLs that return a 301 status code, but there is a 24-hour cooling period before the change is applied. Perhaps that is not enough or not a reliable indicator for a permanent redirect.

It seems odd to me that annualreviews.org uses a 301 status code for this purpose, since 301 means “moved permanently”. Status codes 302 and 307 would be better suited for this purpose (s. rfc7231 S. 6.4 and rfc2616 S. 10.3), since either are meant to be interpreted as temporary redirects. Technically, a temporary maintenance ought to be a different status code altogether, such as 503.

I am not favouring a general user preference for this, since this seems to be a rare occurrence and is non-standard practice. Perhaps it would be possible to add a preference to the Get Info panel for a specific feed to opt out of this.

@barijaona: Any suggestions?

[nathanlesage]

That sounds like a good suggestion. Honestly I would even be happy with a rough plist entry to do that, because you are absolutely correct that a 301 should not cause the problems I experience. I think it may very well be a simple misconfiguration on their side, but being able to counteract such misconfigurations on a per-feed basis is definitely more user-friendly, yes.

Btw in the meantime they both seem to have fixed the issue, since I didn't experience this behavior anymore, but I'm sure this wasn't the last time it happened ...

[barijaona]

I have tested this for a few weeks, but I could not reproduce the problem.

Vienna has already some safety mechanisms regarding 301 redirections. We could enforce additional precautions : update the database only after making sure that the new URL points to data that can effectively be parsed.

[Eitot]

For what it is worth, the annualreviews.org maintenance page has a status code of 503. This is something Vienna could look for when it checks whether to update the URL.

[github-actions[bot]]

This issue hasn't been updated in a while so we're going to mark it as stale. stale issues will automatically be closed after 60 days of inactivity. If this issue is still affecting you, please update us on how it affects you, and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. Thank you for your contributions.

[TAKeanice]

Shouldn't we incorporate one of the suggested changes? I liked the idea to only update the url if the target of the redirection is a feed that Vienna can display... Maybe we could even replace the 24h cooldown that way?

[github-actions[bot]]

This issue hasn't been updated in a while so we're going to mark it as stale. stale issues will automatically be closed after 60 days of inactivity. If this issue is still affecting you, please update us on how it affects you, and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. Thank you for your contributions.