Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 6.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

I have a mixed feeling about this one. PHP_AUTH_PW should always be set when using PHP_AUTH_USER. So, I would rather fix your code instead.

But it's not mine code ¯_(ツ)_/¯
The case is: someone scanning my app with invalid headers and I getting notices in logs. Then params are being validated and rejected properly(or not being used at all), but it's weird when vendor's code(Request::createFromGlobals()) produce notices.

Moreover, if PHP_AUTH_PW should always be set, why do we have isset check on line 41 (instead of exception for example)?

I guess it worth to make behavior consistent. So either remove ?? on line 41 or add ?? for $headers.

@fabpot what do you think?

PHP_AUTH_USER is not supposed to be an HTTP header (accessible through HTTP_PHP_AUTH_USER in the PHP superglobals). I think

Same for PHP_AUTH_DIGEST later in the method

PHP_AUTH_USER is not supposed to be an HTTP header (accessible through HTTP_PHP_AUTH_USER in the PHP superglobals). I think [...] should store those in local variables, not in the $headers array.

Seems like this was introduced as a workaround for fastcgi with Apache in 2.0: #3551 & symfony/symfony-docs#2529

If we were to refactor this, we should probably take care not to break this workaround? (tbh unless this is a critical fix, I would favor not rewriting this 10 year old code, which is the only way to make sure we don't unintentionally break things)

the Apache workaround was adding the support for HTTP_AUTHORIZATION in the else clause. This does not require storing the PHP_AUTH_* values as part of the headers (and as such allowing them to be provided as header by a crafted request too)

@stof @nicolas-grekas @fabpot simplified this one by following Nicolas suggestion. Let's make some decision :)

Thank you @vitman.