Cache busting parameters from RSS readers break bridges

[JasonGhent]

Describe the bug
Some readers implement cache-busting logic in the form of appending a &_=<timestamp> query parameter to sequential requests. Appropriately, this is interpreted by the BridgeAbstract as a parameter to pass to the bridge. Unfortunately, this breaks some bridges.

To Reproduce
Steps to reproduce the behavior:

1. Append &_=123 to any bridge request.
2. See error:

 Exception: Invalid parameters value(s): _ in /app/lib/error.php:24\nStack trace:\n#0 /app/lib/error.php(33): returnError(
)\n#1 /app/lib/BridgeAbstract.php(222): returnClientError()\n#2 /app/actions/DisplayAction.php(133): BridgeAbstract->setDatas()\n#3 /app/index.php(38): DisplayAction->execute()\n#4 {main}

Expected behavior
The bridge abstract should ignore unexpected parameters. Or strip cache-busting earlier in the execution process.

Desktop (please complete the following information):

• OS: MacOS
• Browser Firefox, Chrome, Safari
• Version latest

Additional context
Can fix it by adding a stripping redirect on the index.php file, but that's suboptimal.

/*
 * 301 to strip common cache-busting query parameter to avoid passing bogus parameters to bridges
 */
$url = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on' ? "https" : "http") . "://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
$pos = strpos($url, "_");
if ($pos != false) {
  $url = substr($url, 0, $pos);
  header('Location: '.$url);
  die();
}

[VerifiedJoseph]

The easiest way to handle this would be to add an if statement to the foreach loop in ParameterValidator->validateData() (lib/ParameterValidator.php#L132-L178) that skips &_=<timestamp> style parameters.

e.g:

/*
Some RSS readers add a cache-busting parameter (_=<timestamp>) to feed URLs, detect and ignore them.
*/
if ($name === '_') {
	continue;
}

---

Out of interest, @JasonGhent, what RSS reader are you using? This isn't an issue or RSS reader behavior I've seen before.

[JasonGhent]

@VerifiedJoseph I'm using NewsBlur.

I think I recall seeing this in another reader in the past (TTRSS, maybe?), but I do admit it's on the client moreso than the rss-bridge to fix it.

That said, I thought it makes sense to at least document it (and a potential fix) here.

[em92]

Here is example, how I dealed with unneeded parameter: #894

Can fix it by adding a stripping redirect on the index.php file, but that's suboptimal.

Why that's suboptimal?

[JasonGhent]

Here is example, how I dealed with unneeded parameter: #894

Can fix it by adding a stripping redirect on the index.php file, but that's suboptimal.

Why that's suboptimal?

Extra pageload and associated networking overhead compared to using the way @VerifiedJoseph showed.

[em92]

Extra pageload and associated networking overhead compared to using the way @VerifiedJoseph showed.

I see. Then I agree with @VerifiedJoseph's solution.