HTTP 304 responses for RSS feeds cause enormous alert queues

[sneakers-the-rat]

Please complete the following tasks.

• [x] Web browser cache cleared
• [x] Link provided to install script if applicable
• [x] Not using broken rtinst install script
• [x] Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Web Browser: Firefox Latest ruTorrent 5.1.5 PHP: 8.1 OS: Ubuntu server 22.10

Tell us how you installed ruTorrent

Seedbox provided

Describe the bug

Submitting this on behalf of someone else, asking for followup information.

Original issue: https://codeberg.org/Safeguarding/sciop/issues/399

We run an indexer that serves torrents over RSS. We cache those feeds with nginx, which correctly returns a 304 Not Changed response when the feeds haven't changed since last request. It looks like rutorrent should know how to handle a 304, but apparently 304's cause a growing stack of alert modals - in the description of the OP:

it just keeps piling up, so that after 24 or 48 hours, it takes a long time to load the error messages

Attaching an image they submitted below. Thought you'd like to know!

Steps to reproduce

We have disabled the 304 responses on our feeds in the meantime, but we can re-enable them if it would be helpful for diagnosis. The reproduction steps they provided were "subscribe to any feed and get a 304"

Expected behavior

Not display a modal! 304's are a normal response, especially for RSS feeds that only update sporadically :)

Additional context

Asking for more info in original issue, will edit this as i receive it

[CelianGdfrd]

PHP is 8.1, OS is Ubuntu server 22.10

[stickz]

I've updated the flares on this issue report. The error handling on ruTorrent can definitely be improved.

[ranirahn]

I take a fast look and found this code inside rss.php

if($cli->status<200 || $cli->status>=300) {
			if ($cli->status !== 304) {
                                $msg = $cli->status == -100
                                        ? '[RSS-Timeout]'
                                        : ($cli->status < 100
                                                ? '[RSS-Connection-Error] ' . $cli->error
                                                : '[RSS-HTTP-Error] Status: ' . $cli->status);

                                $this->lastErrorMsgs[] = $msg;
                                return false;
                        }
			// true if feed not modified
			return true;
		}

But that excludes specifically error 304 so I am confused.

Edit: Can you change this

			// true if feed not modified
			return($cli->status===304);

the return get changed because if there was many feeds that give error, the rutorrent crashed. I could not find the reason for returning 304, but maybe there was a reason. So if you change that return statement in this part and see how it works. If it works I need to find another way to fix the crashing of the rutorrent if many feeds give errors. If its still give same error then this was not the problem part.

[SuperMiaw]

I think i found the real culpit, it's the comparison itself. https://github.com/Novik/ruTorrent/pull/2955

Edit: *It won't prevent being flooded by errors though if a lot happens Thanks for fast merge !

[ranirahn]

I see that this was already commited, but isnt that better in this case? the != make it little too open ended I think.

if (intval($cli->status) !== 304)

[SuperMiaw]

The best will be to intval at core inside snoopy utility, but... that would mean way more changes/risks.

You have to take into account the situation where status might be empty which might throw exception.

I'm leaving up to someone else to do better which is definitively possible but higher risk/change/effort. (Probably that should be done on dev though not on master)

[ranirahn]

Well, I take it probably this way that lets see what happens and if there are some errors becaue of this we deal with this then. Maybe there never will be any issue so no point changing it again right now. I was just asking questions. I hope when its released and people who had the error have tested it out and can close this issue and we never hear about it again. That would be the best ✌

[stickz]

@sneakers-the-rat Please confirm a resolution to the problem with ruTorrent v5.2.9. https://github.com/Novik/ruTorrent/releases/tag/v5.2.9

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.