TYPO3 Core

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?

Thanks for the details, so the header is overwritten at a later point.

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.

Andreas Wolf wrote:

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.

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 = 1
config.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?

Roland Waldner wrote:

Andreas Wolf wrote:

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.

hi andreas,

page.config.disableCharsetHeader = 1 actually 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 = 1
config.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).

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.

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.

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.

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 = 1 actually 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.

This seems strange, since the place, where the named option is handled, is the only place where the header is set for frontend.

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 = 1 actually 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?

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

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

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

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

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

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