[TYPO3-core] RFC: #15626: Feature: Add stdWrap to config.additionalHeaders

[Steffen Kamper]

Hi,

Ernesto Baschny [cron IT] schrieb:
> Dmitry Dulepov schrieb am 06.09.2010 12:55:
> 
>> Rik Willems wrote:
>>> Problem:
>>> The config.additionalHeaders is of type string. This is inflexible and
>>> can use improvement.
>>>
>>> Solution:
>>> Add stdWrap to config.additionalHeaders
>> As I wrote in the older thread:
>> ------------
>> Entries in "config" are plain historically. This is made for a reason:
>> 'config' sometimes is used without the rest of TS. So cObj may not have all
>> data necessary to do its work. I did not look to the patch but I think it
>> is better to keep config like it is now. If you need something special, you
>> can always make a userFunc. For "Location" header you can use <meta> tag
>> with "page.headerData".
>> ------------
> 
> I am also not sure if that is right. "config." is still a very valid and
> not only historical entry point for "global configuration" regarding the
> generation of a page. With "page.config" you can overwrite certain
> behaviours on a typeNum scope.
> 
> The main issue with using stdWrap on these properties, is that there
> isn't necessarily access to a valid cObj when certain properties are
> being read, so usually you don't even have access to TypoScript. Some of
> the setting even affect how "stdWrap" behaves (e.g. "locale_all").
> 
> So it is right that the config.* top level array (and its page.config.*
> brothers) are a place where "miscelaneous" settings are made, but we can
> still have stdWrap in certain situations, and this is one of it. In this
> case, additionalHeaders give out HTTP-headers, which you cannot do with
> "page.headerData" level (you can only "emulate" them).
> 

i totally agree here. config is a flat array which only uses plain 
strings for "configuration". I see no usecase where you need special 
handling with stdWrap and these strings, the only matter can be handled 
with simple conditions.

btw - page.headerData should be deprecated as the pageRenderer now gives 
all the options for including stuff to page header including compression 
and concatenate options, which never will be processed in headerData.

vg Steffen