Performance issues when escaping looooong value as html_attr

[Kocal]

Hi everyone, sorry if this issue is a duplicate, but I didn't find anything here.

For reference: symfony/ux#2178

With Symfony UX Map, when you create a Map with 1000 Marker and InfoWindow, the following code takes ~62% of the response time (near ~220 ms) to escape $string (here, a big JSON object which have been stringified):

Twig/src/Runtime/EscaperRuntime.php

Lines 240 to 303 in 126b2c9

	case 'html_attr':
	if ('UTF-8' !== $charset) {
	$string = $this->convertEncoding($string, 'UTF-8', $charset);
	}
	if (!preg_match('//u', $string)) {
	throw new RuntimeError('The string to escape is not a valid UTF-8 string.');
	}
	$string = preg_replace_callback('#[^a-zA-Z0-9,\.\-_]#Su', function ($matches) {
	/**
	* This function is adapted from code coming from Zend Framework.
	*
	* @copyright Copyright (c) 2005-2012 Zend Technologies USA Inc. (https://www.zend.com)
	* @license https://framework.zend.com/license/new-bsd New BSD License
	*/
	$chr = $matches[0];
	$ord = \ord($chr);
	/*
	* The following replaces characters undefined in HTML with the
	* hex entity for the Unicode replacement character.
	*/
	if (($ord <= 0x1F && "\t" != $chr && "\n" != $chr && "\r" != $chr) || ($ord >= 0x7F && $ord <= 0x9F)) {
	return '&#xFFFD;';
	}
	/*
	* Check if the current character to escape has a name entity we should
	* replace it with while grabbing the hex value of the character.
	*/
	if (1 === \strlen($chr)) {
	/*
	* While HTML supports far more named entities, the lowest common denominator
	* has become HTML5's XML Serialisation which is restricted to the those named
	* entities that XML supports. Using HTML entities would result in this error:
	* XML Parsing Error: undefined entity
	*/
	static $entityMap = [
	34 => '&quot;', /* quotation mark */
	38 => '&amp;', /* ampersand */
	60 => '&lt;', /* less-than sign */
	62 => '&gt;', /* greater-than sign */
	];
	if (isset($entityMap[$ord])) {
	return $entityMap[$ord];
	}
	return \sprintf('&#x%02X;', $ord);
	}
	/*
	* Per OWASP recommendations, we'll use hex entities for any other
	* characters where a named entity does not exist.
	*/
	return \sprintf('&#x%04X;', mb_ord($chr, 'UTF-8'));
	}, $string);
	if ('UTF-8' !== $charset) {
	$string = iconv('UTF-8', $charset, $string);
	}
	return $string;

I.. don't know if its more an issue from Twig or a skill-issue from our StimulusAttributes usage.

But do you think something is optimizable here? is it safe to replace 'a very long stringified json object'|e('html_attr') with htmlentities(json_encode('...')? Because this combo improved performances by 62%!

Thanks!

[stof]

inside quoted attribute values, it is safe to use the html strategy.

The html_attr strategy is specifically about the extra rules needed when escaping things in attribute names and unquoted values.

[Kocal]

Indeed, I've reverted my code and used html as escaping strategy, the performances are a lot better!

Thanks @stof!

[javiereguiluz]

@stof could you please explain a bit more what do you mean by "unquoted values"? Maybe show an example?

The Twig docs (https://twig.symfony.com/doc/3.x/filters/escape.html) say this:

html_attr: escapes a string for the HTML attribute context.

[stof]

@javiereguiluz HTML does not force you to put quotes around values of attributes. <input type=text> is valid HTML. When you don't have quotes around the value, it requires a lot more escaping (for instance, any whitespace has to be escaped so that it does not end the attribute value).

The attribute context is the context where you write those attributes.

Looking at the HTML parsing state, it has several state related to parsing attribute pairs: https://html.spec.whatwg.org/#before-attribute-name-state (sections 13.2.5.32 to 13.2.5.39)
As you can see there, the Attribute value (double-quoted) state and Attribute value (single-quoted) state states have very few special characters (basically, only & and the corresponding quote), which are already escaped by the html strategy of Twig. Other attribute-related states (related to attribute names and unquoted attribute values) have much more special characters, which is what the html_attr escaping strategy is about

[fabpot]

We should maybe clarify the docs? Who wants to give it a try?

[javiereguiluz]

Thanks a lot for the details @stof 🙏

[Kocal]

Thanks Google, in fact that's a duplicate of #2615.

I will try to send a doc PR asap :)

EDIT: opened #4324