HTML-ENTITIES encoding replace UTF-8 in meta tags

[petranek80]

After updating zendframework/zend-view (2.10.0 => 2.11.1) meta tags have HTML-ENTITIES encoding instead of UTF-8

e.g.

after downgrade to 2.10.0 is back normal, UTF-8 encodings

[Ocramius]

@petranek80 can you write a test case that demonstrates the regression, please?

[petranek80]

e.g.
<link href="&#x2F;img&#x2F;favicon&#x2F;favicon.ico" rel="shortcut&#x20;icon" type="image&#x2F;vnd.microsoft.icon">

after downgrade to 2.10.0 is back normal, UTF-8 encodings

<link href="/img/favicon/favicon.ico" rel="shortcut icon" type="image/vnd.microsoft.icon">

[Ocramius]

@petranek80 that's not a problem, since the HTML parser will pick up those characters anyway?

[av3]

I saw the same as I wanted to check my meta description and OpenGraph information. It's not very easy to read when looking at the source code in the browser. The reason for that behavior is https://github.com/zendframework/zend-view/pull/164/files.

But as you can see there is an option for auto escpaping. I'm now using the following for the output (in my phtml file for the layout:

<?= $this->headLink()->setAutoEscape(false); ?>

But you can also use the setAutoEscape method earlier. Unfortunately you can use setAutoEscape() for headMeta(), but it has no effect, because $this->autoEscape isn't checked in the HeadMeta.php

[philipp-winterle]

same here! Not sure it is a problem for search engine crawlers to detect the content properly

[froschdesign]

@av3

It's not very easy to read when looking at the source code in the browser.

Please check the HTML code in the developer tools of your browser.

[froschdesign]

@av3

Unfortunately you can use setAutoEscape() for headMeta(), but it has no effect, because $this->autoEscape isn't checked in the HeadMeta.php

Can you create a new issue report for this problem? Thanks!

[Ocramius]

<?= $this->headLink()->setAutoEscape(false); ?>

Please don't do that, unless you are 100% sure that none of the headLink() parameters are information coming from outside your organisation (databases with stored information count as external data).

[Ocramius]

Not sure it is a problem for search engine crawlers to detect the content properly

Crawlers are based on the parsed HTML structure, not on the raw strings: not affected.

[lexxur]

OK we should downgrade zend-view now.

Thanx

[Ocramius]

@lexxur why would you need to?

[DennisDobslaf]

If your ie is set to compatibility mode and you want to send
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
via Zend\View\Helper\HeadMeta like
$headMeta->appendHttpEquiv('X-UA-Compatible', 'IE=edge');
this will lead to the (correct) escaped string
<meta http-equiv="X-UA-Compatible" content="IE&#x3D;edge">
But IE will now fall back to IE 7 Mode (in my case) and because of that, could not find escaped link and script tags.

Can anyone confirm?

As a workaround I send
header('X-UA-Compatible: IE=edge');
before any other, but that does not feel like the right solution.

[froschdesign]

@DennisDobslaf

Can anyone confirm?

I can confirm this behaviour in IE11. The following content doesn't work:

<meta http-equiv="X-UA-Compatible" content="IE&#x3D;EmulateIE7">

And this works:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

[lexxur]

Ok. I just give you some glue: we need to escape just quotes (both, single and double), triangle brackets (<, >) and utf-8 symbols (just in case).

Seems like that's enough.

[Ocramius]

I'd first check with @padraic about that.

[Slamdunk]

@DennisDobslaf I can confirm the bad behaviour for X-UA-Compatible.
Our code:

echo $this->headMeta()->appendHttpEquiv('X-UA-Compatible', 'IE=edge,chrome=1');

Before the update the output was:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

After the update the output is:

<meta http-equiv="X-UA-Compatible" content="IE&#x3D;edge,chrome&#x3D;1">

Althought the latter may be the correct form of representing this tag (with https://github.com/zendframework/zend-escaper/blob/master/src/Escaper.php#L231 according to https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet ) it simply doesn't work 😞

Source: a thousand bank users our app is serving every day that called us mad about our broken app 😃 (issue reproduced and verified)

[weierophinney]

Fixed with #182, and version 2.11.2.