[WIP] core: Add option to disable errors in feeds

[logmanoriginal]

Bridge errors are currently included as part of the feed to
notify users about erroneous bridges (before that, bridges
silently failed).

This solution, however, can produce a high load of error
messages if servers are down (see #994 for more details).

Admins may also not want to include error messages in feeds
in order to keep those kind of problems away from users or
simply to silently fail by choice.

This commit adds a new configuration section "error" with
one option "in_feed" which can be set to "true" to enable
the current behaviour (this is the default option) or to
"false" to disable it.

References #1066

[somini]

In that case, does the error get silently dropped? Can't the bridge requests request some kind of error?

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors

503 looks good to me.

[logmanoriginal]

@somini You mean to return errors this way, right?

rss-bridge/actions/DisplayAction.php

Line 226 in 3b8f3da

header('Content-Type: text/html', true, $e->getCode());

That was actually the original code before returning errors in the feed. I suppose if the option is disabled we can revert to the original behavior.

[somini]

I think that's what I mean. Not just keeping the feed clean of "Bridge returned error" false items, but exposing the error as a HTTP status code for the Bridge request.

I agree that this being a breaking change can be disabled by default.

[logmanoriginal]

I changed the implementation to allow for more options. Three are available right now:

• feed => Errors are included in the feed (default)
• http => Errors are returned as HTTP status code and some HTML content
• none => Error reporting disabled

@somini Does that work for you?

[somini]

LGTM, I have configured my personal instance with the "http" configuration, let's see what happens in the next few days.

[logmanoriginal]

LGTM, I have configured my personal instance with the "http" configuration, let's see what happens in the next few days.

Any news on that?

[somini]

This solves the problem without any side effects.

I still get rate-limited sometimes, but since RSS Bridge sends a HTTP error, the feed reader tries again after some time.
I double checked, and the feed reader is detecting some 503 errors, but it doesn't even expose this problems in the interface, it tries again after some time and the rate limits are gone by then.

This is completely transparent. No more erroneous "Bridge returned error" feed items.

This could even be the default, seems semantically more meaningful, but it would be a breaking change. It should be OK mentioning this on the default config file and on the release notes.

[somini]

I'm still running this on http mode and it's still OK, but I think a special case should be made for HTTP error 302 or 301. Those are the redirects, that should be mapped to some 5xx error instead, otherwise the feed reader will complain about:

302 response missing Location header

508 Loop Detected looks good.

This happened on the Twitter bridge before 2bb9480, it sends you in a redirect loop and those 302 errors are erroneously passed to the outside.

[somini]

Any chance of merging this? I have been using it for months with no issues.

[somini]

a special case should be made for HTTP error 302 or 301. Those are the redirects, that should be mapped to some 5xx error instead

508 Loop Detected looks good.

Implemented this on somini@eb21d6f, will run it on my instance to check for issues.

[somini]

Friendly ping on this issue. I'm running this without issues since June.

Be advised about somini@eb21d6f, to avoid infinite loops. It's a small change.

[logmanoriginal]

Thanks for the reminder, I'll merge this and #1179 now.

[somini]

@logmanoriginal I'm sorry, it seems this particular commit was overlooked:

somini@eb21d6f

This is treating the redirect error codes as special cases and send a different error. Otherwise, this might leads to issues.

[logmanoriginal]

Sorry, totally forgot about that. Would you mind opening a PR for it?

[somini]

Sorry, totally forgot about that. Would you mind opening a PR for it?

Not sure why I did not do that in the first place. It's on #1359