-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
RedirectResponse is sent with invalid content-type when route has non-html default format #54434
Comments
Wonder if the content-type should be kept here.. Same debate took place in fetch repo some time ago : whatwg/fetch#609 |
There is a response body so IMO there should be a content type set with it. |
This seems to be due to the Response::prepare() method. So maybe the RedirectResponse should set its content-type to text/html everytime it sets the response body ? |
Yes that sounds like a reasonable fix. |
chalasr
added a commit
that referenced
this issue
Apr 6, 2024
…se (smnandre) This PR was submitted for the 7.1 branch but it was squashed and merged into the 5.4 branch instead. Discussion ---------- [HttpFoundation] Set content-type header in RedirectResponse | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | no | New feature? | no | Deprecations? | no | Issues | Fix #54434 | License | MIT The RedirectResponse has no content-type set, leading to the response using the "current" one (see issue #54434) As `setTargetUrl` set response body with HTML/UTF-8 content, it seems fair to add the matching header at this moment. (not sure if really a _bug_ or not so i'm targetting 7.1 for now) Commits ------- 954f1af [HttpFoundation] Set content-type header in RedirectResponse
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected
5.x.x, probably even earlier
Description
When a route has a default format set to smth else than html, and a redirect happens, the response format gets set on the redirect response incorrectly (because RedirectResponse always has html as content)
This isn't a huge problem in practice as the browser typically does not render this intermediate page's content, but it is nonetheless incorrect.
How to reproduce
Load /test, check the response headers of the 302:
If the
_format=>json
is removed from the Route, then it uses the correct default:Possible Solution
Perhaps the _format response listener should not mess with RedirectResponse instances?
Additional Context
No response
The text was updated successfully, but these errors were encountered: