Content Type in Cached Output about typoscript_rendering

[helhum]

@sksksksk @manuelportela

This issue is now mitigated with: c61941f

Until this is fixed in TYPO3 you can add the following to your view realated code:

<?php
$GLOBALS['TSFE']->setContentType('application/json');
$GLOBALS['TSFE']->config['config']['contentType'] = 'application/json';

If you do so, typoscript_rendering middleware takes care to send the correct content-type header.

[manuelportela]

Hey @helhum

for future me or others who find this thread: In TYPO3 >=11 the header will be provided by returning $this->jsonResponse(). The typoscript config does not overrule a $this->htmlResponse();

[helhum]

@manuelportela So you are saying that the content type header isn't properly set, when the plugin you are rendering is cached, but it works for uncached plugins?

Does it work for you with TYPO3 8.7?

[helhum]

@manuelportela How do you set the content type to json?

[helhum]

My investigation so far: With cached Extbase plugins and by setting content type with JsonView (or doing similar within your own code), it does neither work with TYPO3 8.7 nor TYPO3 9.5, because the changed content type is not propagated to and thus not restored from cache.

This is an unfortunate shortcoming within TYPO3 and nothing that can easily be changed in typoscript_rendering

[manuelportela]

@helhum

sorry for the delay, I don't have a 8.7 setup for this currently around.

Actually I thought that tsr is setting the content type based on the format attribute. My endpoint is an extbase controller which uses \TYPO3\CMS\Extbase\Mvc\View\JsonView as $defaultViewObjectName.

The render method in TYPO3\CMS\Extbase\Mvc\View\JsonView is setting the content type.

/**
     * Transforms the value view variable to a serializable
     * array representation using a YAML view configuration and JSON encodes
     * the result.
     *
     * @return string The JSON encoded variables
     */
    public function render(): string
    {
        $response = $this->controllerContext->getResponse();
        if ($response instanceof WebResponse) {
            // @todo Ticket: #63643 This should be solved differently once request/response model is available for TSFE.
            if (!empty($GLOBALS['TSFE']) && $GLOBALS['TSFE'] instanceof TypoScriptFrontendController) {
                /** @var TypoScriptFrontendController $typoScriptFrontendController */
                $typoScriptFrontendController = $GLOBALS['TSFE'];
                if (empty($typoScriptFrontendController->config['config']['disableCharsetHeader'])) {
                    // If the charset header is *not* disabled in configuration,
                    // TypoScriptFrontendController will send the header later with the Content-Type which we set here.
                    $typoScriptFrontendController->setContentType('application/json');
                } else {
                    // Although the charset header is disabled in configuration, we *must* send a Content-Type header here.
                    // Content-Type headers optionally carry charset information at the same time.
                    // Since we have the information about the charset, there is no reason to not include the charset information although disabled in TypoScript.
                    $response->setHeader('Content-Type', 'application/json; charset=' . trim($typoScriptFrontendController->metaCharset));
                }
            } else {
                $response->setHeader('Content-Type', 'application/json');
            }
        }
        $propertiesToRender = $this->renderArray();
        return json_encode($propertiesToRender, JSON_UNESCAPED_UNICODE);
    }

Generally I use following snippet to disable cache in development:

[globalVar = TSFE : beUserLogin > 0]
  config.no_cache = 1
  config.admPanel = 0
  page.config.no_cache = 1
[global]

What I did:

Viewhelper to generate URL to API endpoint:

<t:link.action pageUid="1" controller="Api" pluginName="Api" action="getLocations" format=".json">API</t:link.action>

Cached: content-type: text/html; charset=utf-8
Logged in (uncached): content-type: application/json; charset=utf-8

TRY: Additional PageType

<t:link.action pageUid="1" controller="Api" pluginName="Api" action="getLocations" format=".json" additionalParams="{type: 19922}">API</t:link.action>

Setup.typoscript

jsonPage = PAGE
jsonPage {
    typeNum = 19922
    config {
        disableAllHeaderCode = 1
        additionalHeaders = Content-type: application/json, utf-8
        xhtml_cleaning = 0
        admPanel = 0
        debug = 0
    }
}

Same result ...

[manuelportela]

@helhum

I was on the same track. Thank you for your quick and bright support! Is the core team aware of this shortcoming?

[heisenbol]

just stumbled on this issue on a 8.7 installation. I generated an RSS feed through my extension and used a typoscript like

[globalVar = TSFE:type = 58978]
rss = PAGE
rss {
   typeNum = 58978
   config {
       disableAllHeaderCode = 1
       additionalHeaders = Content-type:application/xml;charset=utf-8
       admPanel = 0
        xhtml_cleaning = none
        debug = 0
        disablePrefixComment = 1
        metaCharset = utf-8
   }
}
[global]

On the first view, the content type was set correctly. On subsequent (cached) views, the content type was set to text/html.

The problem is solved by replacing

additionalHeaders = Content-type:application/xml;charset=utf-8
with
additionalHeaders.10.header = Content-Type:application/xml;charset=utf-8

I actually looked at the news extension to see why it was working there and started to recreate the configuration mentioned at https://docs.typo3.org/typo3cms/extensions/news/7.2.0/AdministratorManual/BestPractice/Rss/Index.html
The additionalHeaders form was the only part that was different than my previous configuration