-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpFoundation] Request::getContentType doesn't support multipart/form-data #34240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thank you for this issue. |
Hello? This issue is about to be closed if nobody replies. |
I'm still looking forward to get this issue resolved :) Happy to submit a PR. |
Would love to see this go forwards and would be glad to help if needed. |
I think it's an obvious thing - to see multipart/form-data inside \Symfony\Component\HttpFoundation\Request::initializeFormats. It can be something like 'formData' key |
Thank you for this issue. |
I'd still like to get this issue resolved |
@keichinger if I understand correctly, you propose to add this mapping to the existing content type mappings in Note that this is not my area of expertise, so I cannot say anything about the proposal itself. Hopefully this helps you getting a final answer. 🙂 |
@wouterj good idea :) Will do so as soon as possible |
As per RFC 2045 and RFC 2388, the `multipart/form-data` Content-Type should be used when submitting a mixed form containing files, binary data and non-ASCII data. This commit helps with infrastructure that is directly checking against the `Request::getContentType()` method in scenarios, where a mixed form has been submitted. Resolves symfony#34240
As per RFC 2045 and RFC 2388, the `multipart/form-data` Content-Type should be used when submitting a mixed form containing files, binary data and non-ASCII data. This commit helps with infrastructure that is directly checking against the `Request::getContentType()` method in scenarios, where a mixed form has been submitted. Resolves symfony#34240
As per RFC 2045 and RFC 2388, the `multipart/form-data` Content-Type should be used when submitting a mixed form containing files, binary data and non-ASCII data. This commit helps with infrastructure that is directly checking against the `Request::getContentType()` method in scenarios, where a mixed form has been submitted. Resolves symfony#34240
…ontent-Type (keichinger) This PR was merged into the 5.4 branch. Discussion ---------- [HttpFoundation] Map `multipart/form-data` as `form` Content-Type | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | no | New feature? |yes <!-- please update src/**/CHANGELOG.md files --> | Deprecations? |no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | #34240 | License | MIT | Doc PR | – As per RFC 2045 and RFC 2388 (see https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2), the `multipart/form-data` Content-Type should be used when submitting a mixed forms containing files, binary data and non-ASCII data. Currently, the same logic that would run in regular, non-mixed form scenarios can't run for mixed forms, as soon as it relies on the result of `Request::getContentType()` or anything else that might rely on `Request::$formats` without going low-level and avoiding the implemented abstraction. This PR fixes that. Resolves #34240 Commits ------- e597655 Map `multipart/form-data` as `form` Content-Type
I've asked @nicolas-grekas on Twitter and it felt like he wasn't sure, so I investigated a little bit more and found the following sentence in the specs:
According to https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2:
In my opinion,
Request::getContentType()
, or much ratherRequest::initializeFormats()
should mapmultipart/form-data
toform
, as it's per-spec related to submitting forms with mixed data. Right now the behaviour is to returnnull
, which is confusing and cumbersome when you have a controller action that is called via a regularPOST
and viafetch
+new FormData()
as body from your frontend.I'd be very happy to file a PR to add it to the mapping.
Opinions?
The text was updated successfully, but these errors were encountered: