Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
bug #32348 [HttpFoundation] Accept must take the lead for Request::ge…
…tPreferredFormat() (dunglas) This PR was squashed before being merged into the 4.4 branch (closes #32348). Discussion ---------- [HttpFoundation] Accept must take the lead for Request::getPreferredFormat() | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | n/a | License | MIT | Doc PR | n/a Follow up PR to #32344: if both `Accept` and `Content-Type` are defined, `Accept` must take the lead because it explicitly tells what format the client expect as a response. Before: ``` $ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo' [snip] content-type: text/xml ``` After: ``` $ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo' [snip] content-type: application/json ``` Actually, I'm not sure that inferring the content type of the response using the `Content-Type` provided for the request body is a good idea. The HTTP RFC explicitly states that `Accept` must be used to hint a preferred response format (`Content-Type` on the request indicates the type of associated its the body). I would be in favor of being more conservative: use `Accept` if provided (a best practice anyway), and fallback to the default value (HTML by default) otherwise. WDYT? Commits ------- 60d997d [HttpFoundation] Accept must take the lead for Request::getPreferredFormat()
- Loading branch information