Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEDdnaUo=QwDejnJ64ziY2i-9KbMBgvN-_T7pzR8FfXBK3QHQA@mail.gmail.com>
References: <20160620222835.BC26C1A80609@dd1730.kasserver.com>
 <14352177-1b49-e2ed-56a3-9a770d0ebf95@gmail.com> <CAEDdnaU35=jGotCRVHx8=i7JnTg7yZOffr4dZtTDJ9vhqTNqtw@mail.gmail.com>
 <CAEDdnaUo=QwDejnJ64ziY2i-9KbMBgvN-_T7pzR8FfXBK3QHQA@mail.gmail.com>
Date: Fri, 1 Jul 2016 00:35:06 +0500
Message-ID: <CAEDdnaWUNpPxnwymdCj5hrOD=P01BmYO+xJD5JHTy98TRHaLuA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Thomas Bley <mails@thomasbley.de>, PHP Internals <internals@lists.php.net>, 
	rowan.collins@gmail.com
Content-Type: multipart/alternative; boundary=001a113b9dc4a9b2eb053683f75a
Subject: Re: [PHP-DEV] New escaped output operator
From: michael.vostrikov@gmail.com (=?UTF-8?B?0JzQuNGF0LDQuNC7INCS0L7RgdGC0YDQuNC60L7Qsg==?=)

--001a113b9dc4a9b2eb053683f75a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've tried to gather all arguments for and against.

To be clear. I suggest new operator like '<?~ $value ?>' which is
equivalent of <?=3D htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE) ?=
>.
It is only for HTML context. Flag combination is taken from most popular
frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
operator and default flags are the details of implementation.



- You can write short function in userland.

The problem is not that we have no function. The problem is that the same
action is always repeated, and if we don't repeat it then it leads to
security problems. More than 90% of output data - is data from DB and must
be HTML-encoded.

There is no such problem with other contexts. If we don't call json_encode
when passing an array or object into javascript, this only breaks the
script, and it will be noticeable, there won't be security problems.

With new operator we can write or <?~ ?>, or <?=3D ?>, they are mutually
exclusive, and we need specially write one or another, but with helper
function we have the same beginning <?=3D and then can write helper functio=
n
or not.

Also there is a problem with function autoloading.



- It is no place for such operators in the language.
It is no place for a such operators in C++, or C#, or Java. But in the most
popular language for web-programming it is very place for such operator.



- There are many other contexts

HTML is external context, but others are internal task-dependent contexts.
HTML can be used together with other contexts.
HTML context is the main context in every PHP file, and we write <?php at
the beginning to switch it.

Actually, on web page we have 3 external contexts - HTML, <script> tag,
<style> tag.
PHP+CSS usually is not used. PHP+JS is not just escaping. It is encoding in
special notation.
Escaping can be applied only to strings, but encoding can be applied to any
type of variables.

Only urlencode is really escaping (and it also can be used together with
other contexts). But urlencode is an internal context. If we construct an
URL, e.g. for filters, we should encode every part.

$filterUrl =3D '/my_route/?state=3Dactive';
if ($postData['contains_text']) $filterUrl .=3D
'&contains_text=3D'.urlencode($postData['contains_text']);

When we write data-attirbute, additional context is task-dependent, but
HTML context is always present.

<div class=3D"some-class"
    data-url=3D"<?=3D
htmlspecialchars('/my_route/?state=3Dactive&category_id=3D123') ?>"
    data-settings=3D"<?=3D htmlspecialchars(json_encode($settings) ?>"
></div>



- Other people will ask about operator for another context
And you can say: We already added an operator for the main web context,
because it is the most frequently used context. If you have a lot of work
with other contexts, please use template engine.



- You want to add new operator just for your needs
It's not only my needs for one project. I meet this problem in many
projects without template engine. The results of the poll, which I wrote
about in my previous message, show that it has a place not only for me.
Some feature requests on http://bugs.php.net with the same question were
created in 2002.



- Some people can use various flags, or use third and fourth parameters of
htmlspecialchars().

How many such projects of total number of projects?
Default flags can be set to be enough safe. Third parameter can be chaged
via ini_set. Fourth parameter is not required for many cases. Except maybe
when some people encode the data before saving it into database.
Also, new operator is not a replacement for htmlspecialchars, so it could
still be used.

It just is looked not very good - we use special set of parameters, so you
cannot add operator which we could not use.

This problem with flags can be solved by adding default value for them with
PHP_INI_USER mode, and getter and setter for it. But I'm not sure you think
this is a good idea.



- Exact flags / Default flags

In popular frameworks there are the following flags:

Symfony =E2=80=94 ENT_QUOTES | ENT_SUBSTITUTE
Yii =E2=80=94 ENT_QUOTES | ENT_SUBSTITUTE
Zend =E2=80=94 ENT_QUOTES | ENT_SUBSTITUTE
Twig =E2=80=94 ENT_QUOTES | ENT_SUBSTITUTE

https://github.com/symfony/symfony/blob/f29d46f29b91ea5c30699cf6bdb8e65545d=
1dd26/src/Symfony/Component/Templating/PhpEngine.php#L421
https://github.com/yiisoft/yii2/blob/c370c17e93f364a843ed7c31e1e1f7fc8caef0=
a3/framework/helpers/BaseHtml.php#L104
https://github.com/zendframework/zend-escaper/blob/1a855b5f7074607b1260d85c=
5526a59b1ab36593/src/Escaper.php#L117
https://github.com/twigphp/Twig/blob/f0a4fa678465491947554f6687c5fca5e482f8=
ec/lib/Twig/Extension/Core.php#L1039



- Tilde sign
There is a good argument about tilde sign. It is absent in keyboard layouts
for some european languages. But it is the details of implementation.
I think it should be special sign which is typed with Shift and is located
rather far from "=3D" sign. Possible variants are "<?! ?>", "<?@ ?>", "<?^
?>". First variant looks more suitable.



I don't see any arguments, why other operators can be implemented but this
operator cannot.

So, please tell me, what do you think about RFC?



2016-06-29 21:39 GMT+05:00 =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=92=D0=
=BE=D1=81=D1=82=D1=80=D0=B8=D0=BA=D0=BE=D0=B2 <michael.vostrikov@gmail.com>=
:

> Hello. I've created an article on russian technical site habrahabr.ru.
> https://habrahabr.ru/post/304162/
>
> There is a poll about introducing of such operator. About 60% from those
> people who have projects without template engine are "for" this operator.
> And even a half of those who don't also think that such operator can be
> useful.
>
> I think you can use Google Translate to read it, common sense and code
> examples should be understandable.
>
> https://translate.google.com/translate?sl=3Den&tl=3Dru&js=3Dy&prev=3D_t&h=
l=3Dru&ie=3DUTF-8&u=3Dhttps%3A%2F%2Fhabrahabr.ru%2Fpost%2F304162%2F&edit-te=
xt=3D&act=3Durl
>
> Current results:
>
>
> How often do you work with the projects with template rendering on PHP
> where template engines are not used?
> 35% (163)  Always
> 22% (104)  Quite often
> 18% (86)   Quite rare
> 25% (117)  Almost never
>
> Voted 470 people. Abstained 116 people.
>
>
> How do you think, such an operator would be useful?
> 56% (264)  Yes
> 44% (207)  No
>
> Voted 471 people. Abstained 121 people.
>
>
> I don't use PHP teplate rendering ...
> 51% (147)  and I think that such an operator is not needed
> 49% (139)  but I think that such an operator will come in handy
>
> Voted 286 people. Abstained 247 people.
>
>
> Screenshot in Russian:
>
> https://habrastorage.org/files/675/9ac/883/6759ac8834044ef0b5a09163c791f3=
76.png
>
>
> 60% are "for" this operator, projects of others 40% will not be affected.
> I think this is a good reason to create an RFC and discuss it on more
> global level.
>
>

--001a113b9dc4a9b2eb053683f75a--