Bug #60624
closed
JSON view does not set HTTP header field "Content-Type" correctly
Added by most wanted over 10 years ago. Updated about 6 years ago.
100%
Description
The TYPO3 Flow's JSON view was backported to TYPO3 6.2. Using it should result in a HTTP response with HTTP header field "Content-Type" set to "application/json".
Although TYPO3\CMS\Extbase\Mvc\View\JsonView::render() sets the HTTP field "Content-Type" in the first place, but finally it is not delivered to the browser/API client.
Files
| Screenshot at Juli 27 22-27-43.png (184 KB) Screenshot at Juli 27 22-27-43.png | most wanted, 2014-07-27 22:34 | ||
| Screenshot at Juli 27 22-34-11.png (125 KB) Screenshot at Juli 27 22-34-11.png | most wanted, 2014-07-27 22:34 |
Updated by Markus Klein over 10 years ago
- Status changed from New to Accepted
Good point. The reason is that the send() method of the Response object is never called, which would take care about the headers.
Updated by Markus Klein over 10 years ago
Hm, but the shutdown() is called, which should also send the headers.
Seems like the check on headers_sent() inside the sendHeaders() function prevents sending them.
Can you please debug, if the code runs into this check?
Updated by most wanted over 10 years ago
- File Screenshot at Juli 27 22-27-43.png Screenshot at Juli 27 22-27-43.png added
- File Screenshot at Juli 27 22-34-11.png Screenshot at Juli 27 22-34-11.png added
Markus Klein wrote:
Hm, but the shutdown() is called, which should also send the headers.
Seems like the check on headers_sent() inside the sendHeaders() function prevents sending them.
Can you please debug, if the code runs into this check?
- sendHeaders() is called
- headers_sent() returns FALSE
- header($header) is called
- resulting HTTP header field "Content-Type" in browser/API client is text/html; charset=utf-8
Please have a look at the enclosed screenshots.
Updated by Markus Klein over 10 years ago
Thanks for the details, so the header is overwritten at a later point.
Updated by Andreas Wolf over 10 years ago
As far as I can see, this problem comes from TypoScriptFrontendController overwriting the charset header again. This can be disabled with page.config.disableCharsetHeader = 1.
@Roland: please check and if it helps, we could close this bug. Probably this information should be placed in the doc comment of JsonView.
Updated by most wanted over 10 years ago
Andreas Wolf wrote:
As far as I can see, this problem comes from
TypoScriptFrontendControlleroverwriting the charset header again. This can be disabled withpage.config.disableCharsetHeader = 1.@Roland: please check and if it helps, we could close this bug. Probably this information should be placed in the doc comment of JsonView.
hi andreas,
page.config.disableCharsetHeader = 1 actually really leads to the correct HTTP header field "Content-Type". Thx.
I am not sure if this is a good solution. As far as i know you need 2 TypoScript settings to be able to use the JsonView sensefully:
page.config.disableCharsetHeader = 1config.disableAllHeaderCode = 1
I guess this should both be guaranteed by the view itself, shouldn't it? E.g. to give you the flexibility to use different Views on the same page (via the format option: e.g. html and json).
Am I missing something?
Updated by Andreas Wolf over 10 years ago
Roland Waldner wrote:
Andreas Wolf wrote:
As far as I can see, this problem comes from
TypoScriptFrontendControlleroverwriting the charset header again. This can be disabled withpage.config.disableCharsetHeader = 1.@Roland: please check and if it helps, we could close this bug. Probably this information should be placed in the doc comment of JsonView.
hi andreas,
page.config.disableCharsetHeader = 1actually really leads to the correct HTTP header field "Content-Type". Thx.
Great that it works for you!
I am not sure if this is a good solution. As far as i know you need 2 TypoScript settings to be able to use the JsonView sensefully:
page.config.disableCharsetHeader = 1config.disableAllHeaderCode = 1I guess this should both be guaranteed by the view itself, shouldn't it? E.g. to give you the flexibility to use different Views on the same page (via the format option: e.g. html and json).
You're right, this is a less-than-ideal solution. The problem is that Extbase does not handle the full page rendering process, unlike Flow. Extbase is just a framework for the building blocks, but the building itself is constructed by the CMS core. Therefore it's hards for Extbase to completely control parts of the outer world, like the header generation. Applications like an API should IMHO rather be implemented as an eID script that does not need the full-blown page generation mechanism, instead of a regular page plugin that suffers the same limitations.
The problem comes from the JsonView being a rather direct backport from Flow, where all this is possible - but as said, for Extbase things are a bit more complicated :(
If you agree, I'll close this report as "not a bug" because it's a misconception in Extbase's JsonView, but that should be tackled differently.
Updated by most wanted over 10 years ago
Andreas Wolf wrote:
I guess this should both be guaranteed by the view itself, shouldn't it? E.g. to give you the flexibility to use different Views on the same page (via the format option: e.g. html and json).
You're right, this is a less-than-ideal solution. The problem is that Extbase does not handle the full page rendering process, unlike Flow. Extbase is just a framework for the building blocks, but the building itself is constructed by the CMS core. Therefore it's hards for Extbase to completely control parts of the outer world, like the header generation. Applications like an API should IMHO rather be implemented as an eID script that does not need the full-blown page generation mechanism, instead of a regular page plugin that suffers the same limitations.
The problem comes from the JsonView being a rather direct backport from Flow, where all this is possible - but as said, for Extbase things are a bit more complicated :(
Thank you for your explanation.
If you agree, I'll close this report as "not a bug" because it's a misconception in Extbase's JsonView, but that should be tackled differently.
Yes, that is fine for me.
Updated by Markus Klein over 10 years ago
I will discuss this topic with A. Schnitzler whether there's a way to avoid that the Core overrides already defined headers like content-type.
Updated by most wanted over 10 years ago
Andreas Wolf wrote:
@Roland: please check and if it helps, we could close this bug. Probably this information should be placed in the doc comment of JsonView.
hi andreas,
page.config.disableCharsetHeader = 1actually really leads to the correct HTTP header field "Content-Type". Thx.
It seems that it only results in the correct HTTP header field "Content-Type" (application/json) if you are logged into the TYPO3 backend and do a "force refresh" (Shift+Cmd+R) in your browser.
Updated by Markus Klein over 10 years ago
This seems strange, since the place, where the named option is handled, is the only place where the header is set for frontend.
Updated by Andreas Wolf over 10 years ago
Roland Waldner wrote:
Andreas Wolf wrote:
@Roland: please check and if it helps, we could close this bug. Probably this information should be placed in the doc comment of JsonView.
hi andreas,
page.config.disableCharsetHeader = 1actually really leads to the correct HTTP header field "Content-Type". Thx.It seems that it only results in the correct HTTP header field "Content-Type" (application/json) if you are logged into the TYPO3 backend and do a "force refresh" (Shift+Cmd+R) in your browser.
We're using that setting in a project and it always works. Please check if you have some TS condition or the like applied in the area where you inserted page.config.disableCharsetHeader.
Oh, btw: what version are you using exactly?
Updated by Gerrit Code Review almost 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Gerrit Code Review almost 10 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34839
Updated by Helmut Hummel almost 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 6c0191f47afe5f14cb15c115f572c8ffae6dfbf9.
Updated by 
