#1375 ID: 2860271 comment

[Darren J. Young]

Don't seem to be able to comment on "ID: 2860271" not that you've rejected and closed it.

It's your call, but if this is "as designed", it's a deficient design in my opinion. Reasonable effort should be made to protect the integrety of the users data.

Obviously, if there's a intentional effort on the part of system who's intent is questionable, those efforts are more difficult to deter, but if it's just the matter of a poorly designed proxy, that's a different story. I didn't ask for nearly 1000 feeds to be rewritten and it's doubtful the proxy of the hotel actively reverse wngineered the internal structure of RSS Bandit's feed storage and rewrote them. RSS Bandit changed them and it shouldn't have.

I'd really like to understand how this "as designed", was designed to benefit me because in this case it didn't. I'd like to think the average less tech savy user likely woun't have been able to correct the issue as I did. If the software is designed to destroy their feeds without notice when connecting through a poorly design proxy (something they'd typically have no knowledge of the proxy's design) then I guess it is as designed and worknig perfectly well.

If you would please reconsider your decision, I'd greatly appreciate it. If you think the design should stay, I'd love to know why as a user I want it the way it is.

Obviously as with anything, a free software is you get what you pay for and you're obligated to do nothing. But without plans to correct this issue or offer some safegaurds to the unsuspecting end user, or an explaination as to why I should prefer it as is, or how I'd know in the future a person should reasonably know and have the ability to prevent this, I'll have to find another solution. I simply can't continue to use a software package that views putting my data at risk for corruption "as designed" without it being corrected or my understanding where I was negligent in the cause of this.

[Torsten Rendelmann]

The "HTTP 301 Perma Redirect" is used to automatically maintain the feed links: often blogs are moved around from one host to another, and the old link will return a "301" to indicate the movement and direct to the new location. So we automatically adjust the feed url(s) that way no user has to manually look where the feed is gone now.

The Hotel proxy should have used a HTTP 302" instead, a temporary redirect - that return code does NOT make the feed urls changed.

So we think the issue is with the Hotel network, not a issue with the software.

[Darren J. Young]

Ok, that makes perfect sense. I'd still like an option that controls this behaviour or better yet, while I agree that it's the hotel's service's issue, it seems like a reader should be able to detect this...while it's common for a site to relocate and redirect, it's not likely 1000 of they are at the same time.

It would be nice if there was a way to detect this (number of feeds at once or the 10% of the total requesting a permanent change, etc).

[Darren J. Young]

PS...while it is an issue with the service the hotel uses, this also does seem like something that could be exploted rather easily by someone less reputable wanting to do harm.

Appropriate and reasonable dillegence (not jumping through hoops) should be taken to prevent the user from harm from this IMO.

But thanks again for the explaination. My software development experiance doesn't extend to web based development.

[Torsten Rendelmann]

I think, that is really a very "technical" issue: so I would not vote for a option a user should be able to configure - I think, it would be always switched on.
In the one case (you imagined, sorry for that) you might have to know the issue BEFORE it occurs to switch it off before first use at the new location - that is very unlikely to happen. Who knows about a "hotel" issue before he will hit?
Also the mentioned "heuristic" will not really work: just take some big blog hoster like blogger.com. Usually most of the blogs will have the same root Uri. Now assume, the hoster have to move some blogs (or all) to another root location (e.g. to opt. perf. or disk storage, or just group by themes) - they would use the perma redirect to accomplish that and get all the favorite bookmarks in the browsers (and RSS Bandit feeds) updated to the feeds/pages new locations. Then we would detect a false positive with that heuristic.
And I don't think, IE or Firefox has such a heuristic implemented.
Also, such issues are very rare - you are the first one I ever heard of with such a problem) and the solution was not so complicated to work around - for users with fewer IT experiences we would have taken over that as a support request to just fix the feed file of that particular user.

And BTW. if a key logger gets your passwords or banking account data, that is "real" harm compared to this issue, sorry.
Hopefully you have bothered the Hotel Service Personal with that issue - that would be the right place it should get fixed IMO.