Hey!

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

Symfony has acontribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (seehttps://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://symfony.com/releases)
• Features and deprecations must be submitted against the 6.4 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

Maybe I'm wrong but seems that something related tomapQueryString andmapRequestPayload is in this file and I see nothing from yours :

Why did not add in the same file?

Too bad the PR was changed after@robert-sykes suggestion. I think these are 2 distinct ideas. The original PR description mentions a single attribute per header, same as how MapQueryParameter works. There are valid cases for that, where you only want and need a single header scalar.

The updated code now requires you to map a header to a header object.

Would be great to also keep supporting the original one for just a single header.

See this comment where a similar situation happened:#49134 (comment)

Too bad the PR was changed after@robert-sykes suggestion. I think these are 2 distinct ideas. The original PR description mentions a single attribute per header, same as how MapQueryParameter works. There are valid cases for that, where you only want and need a single header scalar.

The updated code now requires you to map a header to a header object.

Would be great to also keep supporting the original one for just a single header.

See this comment where a similar situation happened:#49134 (comment)

I'm all for this, to be fair. I did imply this in my original comment where I saidYou can merge it with your current concept and have a bit of best of both? Map individual Headers to an string, or an object or even just an array if required? That said - I didn't push it any further in my commentary, apologies.

@StevenRenaux You could check the type and if it's a string map to that similar to your original commit, otherwise if it's object map to those fields instead. We get best of both worlds this way. What do you think?

Hey, I will try to do it and I didn't understand well for sure but we are there to share and go further 😉

Hey, I will try to do it and I didn't understand well for sure but we are there to share and go further 😉

No problem at all. If you need a hand let me know, more than happy to pair on this with you. :)

To get back to the original Issue I suggest this

namespaceApp\Controller;class TestControllerextends AbstractController{    #[Route(path:'/', name:'test')]publicfunctiontest(        #[MapRequestHeader]HeaderRequestDto$headerRequestDto,        #[MapRequestHeader(name:'user-agent')]string$agent,        #[MapRequestHeader]array$accept    ):Response    {dd($headerRequestDto,//      App\Entity\HeaderRequestDto {//        accept: "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"//        agent: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0"//        acceptEncoding: "gzip, deflate, br"//        host: "localhost:8000"//      }$agent,//      "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0"$accept//      array:6 [//          0 => "text/html"//          1 => "application/xhtml+xml"//          2 => "application/xml;q=0.9"//          3 => "image/avif"//          4 => "image/webp"//          5 => "*/*;q=0.8"//      ]        );    }}

And a Dto could look like this :

namespaceApp\Entity;useSymfony\Component\Serializer\Annotation\SerializedName;useSymfony\Component\Validator\ConstraintsasAssert;class HeaderRequestDto{publicfunction__construct(publicreadonlystring$accept,        #[Assert\EqualTo('test', groups: ['test'])]        #[SerializedName('user-agent')]publicreadonlystring$agent ='agent',        #[SerializedName('accept-encoding')]publicreadonlystring$acceptEncoding,        #[Assert\EqualTo('localhost', groups: ['valid'])]publicreadonlystring$host    ) {    }}

We only use kebab-case (as returned by HeaderBag) now to get some property like 'user-agent'.
And if we want an array rather than a string for the property asaccept it will return an array after an explode with a coma delimiter.

Hi@StevenRenaux! What's the current state of this PR? 🙂

Hi@StevenRenaux! What's the current state of this PR? 🙂

@alexandre-daubois Waiting for review, since the last requested update.

Back to the basics of PR, using only the MapRequestHeader attribute. Mapping to a DTO does not seem like a relevant or common use case or if it is really necessary could be done in a future PR.

The allowed types are therefore:

• string
• array
• AcceptHeader

When the header parameter cannot be determined by the variable name, we can specify the name argument in the attribute.

publicfunctiontest(    #[MapRequestHeader('user-agent')] ?string$bar,):Response{dump($bar);//  "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"}

If we are looking for a header of type Accept-* with an array type, we will use the dedicated methods to retrieve this data.

https://symfony.com/doc/current/components/http_foundation.html#accessing-accept-headers-data

publicfunctiontest(    #[MapRequestHeader]array$accept,):Response{dump($accept);//        array:7 [▼//          0 => "text/html"//          1 => "application/xhtml+xml"//          2 => "image/avif"//          3 => "image/webp"//          4 => "image/apng"//          5 => "application/xml"//          6 => "*/*"//        ]}

And with AcceptHeader type

publicfunctiontest(    #[MapRequestHeader(name:'accept-encoding')]AcceptHeader$encoding,):Response{dump($encoding);//        Symfony\Component\HttpFoundation\AcceptHeader {#4727 ▼//            -items: array:4 [▼//                "gzip" =>//                    Symfony\Component\HttpFoundation\AcceptHeaderItem {#2437 ▼//                        -value: "gzip"//                        -quality: 1.0//                        -index: 0//                        -attributes: []//                }//                "deflate" =>//                    Symfony\Component\HttpFoundation\AcceptHeaderItem {#4882 ▼//                        -value: "deflate"//                        -quality: 1.0//                        -index: 1//                        -attributes: []//                }//                "br" =>//                    Symfony\Component\HttpFoundation\AcceptHeaderItem {#4549 ▼//                        -value: "br"//                        -quality: 1.0//                        -index: 2//                        -attributes: []//                }//                "zstd" =>//                    Symfony\Component\HttpFoundation\AcceptHeaderItem {#4773 ▼//                        -value: "zstd"//                        -quality: 1.0//                        -index: 3//                        -attributes: []//                }//            ]//              -sorted: false//        }}

It bugs me thearray type has two semantics whether it applies to anAccept-* header or not. Plus

• in the first case there already is theAcceptHeader type.
• in the second case only the first value is returned in an array, but
  • there can be many
  • the first value can actually be many values combined by the SAPI

@StevenRenaux What's needed to get this to a mergeable state? I would love this to be included in the new Symfony version.

@StevenRenaux What's needed to get this to a mergeable state? I would love this to be included in the new Symfony version.

@ruudk Waiting reviews from core-contributors, but it's seems to late for merging into the next 7.3 version.
Feel free also to review, approve...
I think at the moment it's fine to get a simple implementation as it is because it's the kind of stuff you can't statifies every problematics.

Could you rebase it, so that the tests go green?

@StevenRenaux Thanks! 🙏 It needs a few tweaks inhttps://github.com/symfony/symfony/actions/runs/15253101552/job/42894283925?pr=51379