Incompatibility with media_entity_download

Hi @penyaskito,

It sounds a bit strange to me, as overrideGlobals() is called during form builds and other modules routines, etc.
So (maybe) it is more of an issue with the media_entity_download module itself.

Still, I have installed the media_entity_download module and cannot reproduce the issue.
Either for inline or attachment GET parameters for media download links, no additional redirects occur.

overrideGlobals() does not change either $_GET["inline"] or $_REQUEST["inline"].
As well, as $event->getRequest()->request->get("inline"); returns null before and after overrideGlobals().

Could you please provide a few more steps to reproduce?
Or, maybe the issue is gone on the latest Drupal 11 + reverse_proxy_header / media_entity_download versions?

Looking forward,

This is similar to https://www.drupal.org/project/linkit/issues/3399995 🐛 If a suggestion has a NULL in query string, LinkitFilter replaces with an empty string Needs review .

OverrideGlobals normalizes the query string:
https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/HttpFo...

Which transforms any null query argument to an empty string. But those aren't the same!

Christian, it normalizeQueryString for $_SERVER and $_REQUEST superglobals variables. We can just debug before and after overrideGlobals() to validate this (a quote from the previous comment):

overrideGlobals() does NOT change either $_GET["inline"] or $_REQUEST["inline"].

I have additionally run this code before and after overrideGlobals() executions:

        $values = [
          $event->getRequest()->query->all(),
          $event->getRequest()->query->get("inline"),
          $_GET["inline"],
          $_REQUEST["inline"],
          $_SERVER["REQUEST_URI"],
        ];

All variables are intact and unchanged. The code was run at clear Drupal11+reverse_proxy_header+media_entity_download (without any other modules).

At this point, there is no understanding of what exactly is changing by overrideGlobals().
Could you please provide:
- the exact variable / superglobal path / request object property which is changing?
- steps to reproduce the mentioned unnecessary redirect?

Thanks.

Don't think I'll be able to test this soon-ish.

If you are using a git checkout of 11.x for testing, this might explain why you can't reproduce, as it might have been fixed in https://github.com/symfony/symfony/pull/59134/files

📌 Update Composer dependencies for 11.1.0-RC1 Active