I assume the & should be a & for passing parameters correctly thinking

Why do you assume this? Ambiguous ampersands in HTML do have to be encoded for the HTML parser to know you are referring to the & character. (At least I think, unless this change in recent HTML versions)

Thanks @voxspox I tested this and things work correctly this way. If there's something not working this way please comment here and I'll be happy to reopen.

Why do you assume this? Ambiguous ampersands in HTML do have to be encoded for the HTML parser to know you are referring to the & character. (At least I think, unless this change in recent HTML versions)

It looks like it did changed (but not recently) to allow ...php?idsite=1&rec=1 not being ambiguous anymore. cf. https://mathiasbynens.be/notes/ambiguous-ampersands:

Later the spec was changed, and the HTML spec now defines ambiguous ampersands as follows:

An ambiguous ampersand is a U+0026 AMPERSAND character (&) that is followed by one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, and U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, followed by a U+003B SEMICOLON character (;), where these characters do not match any of the names given in the named character references section.

This definition is probably easier to grok as a regular expression: a string contains an ambiguous ampersand if it matches /&([0-9a-zA-Z]+;)/ and if the first back-reference ($1) is not a known character reference.

Thanks for the issue and answer though: When reading ...php?idsite=1&rec=1 in the code of a Matomo-using application I wasn't really sure if I had a bug or not, now I have the reason for my doubts and the confirmation it works. 👍