Note: I’m not an user of TT-RSS myself, but I have a blog that people with TT-RSS are reading.
I currently have a number of people subscribed to old URLs of my feed, which are currently reporting a 301 (Moved Permanently) status to a new URL (namely /articles.rss → /index.xml). Despite 301 being a permanent status, TT-RSS does not update its storage of the URL and keep using the old URLs.
While this is mostly an annoyance, it would about halve the bandwidth used by these installations.
Probably not. A 30x redirect is just a header with a new URL; it’s bytes in size. Compared to the end result, which should be the feed itself at several kilobytes. (What it would do is potentially halve the number of requests, assuming one redirect. 
)
The way I see it: if a user bookmarked a page on a web site, the 301 response would not change their bookmark’s URL. So neither does it in TT-RSS.
What I think would be beneficial is for TT-RSS to report it in the UI somewhere so the user can update the URL before the old one is gone. Maybe @fox could comment on that.
As for the double in size: probably not without implementing proper caching with If-Modified-Since, but a 301 is still a significant amount of bytes in headers both sent and received. Let’s call it double in a world where TT-RSS is not extremely wasteful by not caching previous state.
But for not changing the bookmark URL, you’re actually incorrect. See Best practices for syndication feed caching | Ctrl blog and in particular the reference to RFC7238 (this talks about 308, but 301 is the same):
“The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.”
“Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.”
(308 is just 301 without the POST→GET change capability.)
is your server hosted on dialup in 2001 or something? the “waste” here is absolutely inconsequential. opening a huge can of worms by automatically updating feed URLs in the database is much, much worse than this entirely imagined problem - imagine a successful MITM attack permanently fucking over your users’ database.
also, nobody in the world (except for you, i guess) actually uses http code 308.
putting aside blinding stupidity about bytes wasted on http redirects, if the feed is broken it’s really not that hard to just visit the site and get an updated URL - i don’t think adding additional complexity with stuff like multiple URLs stored per feed and keeping track of all this crap is really necessary for this particular scenario.
however, someone interested might try taking on this problem with a plugin, i think we have all the necessary hooks for it.
e: also, get a load of this. op unironically called me a nazi sympathizer on twitter because of this thread:
kekking hard atm
… I just starting writing a reply but figure it wasn’t worth it because
And it doesn’t seem that the OP understands how HTTP works wrt redirects, etc.
e: He’s probably going to be upset when I mention that his subscribers can just change the TT-RSS user agent. 
i’m somewhat surprised it took so long for my frog avatar to trigger some twitter imbecile. benefits of obscurity i guess.
I’m kinda doubting he’s got anything worthwhile to read, anyway.
14MB a day!!!111 start coding fox 
literally 12 people reading his blog caused this whole autistic meltdown
really activates my almonds
Welp, yesterday’s post was about NewsBlur using his bandwidth.
Any wagers what tomorrow’s is?
best part is how he has to ~waste bytes~ sending out http 401 replies to tt-rss clients now, lol
Some people are just idiots I guess…
the silver lining here being that i finally bothered to reimplement http 304 support, properly this time (i hope). it should be up on gogs soon. report broken feeds for proper shaming.
