Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94711
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEDdnaWm-fUoBRdrce=DF8By6ybkTe_ca_niV2xdQp4yecU6Rw@mail.gmail.com>
References: <CAEDdnaWVYbh=t1-bvDh9fixCoC7Be4asoEus=dRhGggx_9VLNg@mail.gmail.com>
 <8a39df34-4a23-c496-15f6-20a62d27fc59@gmail.com> <CAEDdnaWwUUVV6q1Sh+pXNQEAENXHHbJ=ZPaq4otnpnFPwVD-5A@mail.gmail.com>
 <CAObuZdvy9F3sLu=MArNEvh3ZxFkZ=byb7UbH0Gaw2sx=C0QRzw@mail.gmail.com>
 <CAEDdnaV8Qaoib6=v+NBCYYymtQQgyr28qryJ1dBHhVsXqWu5kA@mail.gmail.com>
 <4920f683-9a4d-7153-b157-a7d7ce8cbfe7@gmail.com> <933449d0-90c2-0d7a-cb80-a171289d8286@texthtml.net>
 <CAGovj_PiUjJmAncZjrtTiJmBTmuwA1MgfpjwpkKWdp_NHPekpw@mail.gmail.com>
 <CAEDdnaWEwNH-+kOxPk2GDqRod90kOqbT1yGHkOMqx5L9AXRaLA@mail.gmail.com>
 <CAEDdnaVrAvMHzj=bxhp9fOEFRgJ3rY9Tn9XP0oPfYZ0EU-RrjA@mail.gmail.com>
 <20160724145557.D52C31A80BBD@dd1730.kasserver.com> <6cfac572-9982-87f8-5a55-9213d978cde9@gmx.de>
 <20160724162103.BC5741A83512@dd1730.kasserver.com> <efdfdd99-77d9-f722-7000-13b4528dd77c@gmx.de>
 <20160724172131.675AC1A800B0@dd1730.kasserver.com> <9bc0db6a-fa19-5f87-0e82-3702dcb34254@gmx.de>
 <CAEDdnaWm-fUoBRdrce=DF8By6ybkTe_ca_niV2xdQp4yecU6Rw@mail.gmail.com>
Date: Tue, 26 Jul 2016 18:15:20 +0500
Message-ID: <CAEDdnaVx2Rx0pe+ZCzP=rpWW8OiQ73opmRhLCho_MwV1NRAiaw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0566ce6c8058053889b10f
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: michael.vostrikov@gmail.com (Michael Vostrikov)

--94eb2c0566ce6c8058053889b10f
Content-Type: text/plain; charset=UTF-8

>> if ($context == 'html') {
> this is bad coding style since $context = 0 gives unexpected html
escaping.

I know, it was just an example)


> The RFC speaks of *operator*, where actually start-tags[1] are meant, to
start with.
> Using the word operator is rather confusing in this context.

Technically yes, but there are echo operator, so it can be considered as
special construction for using echo operator. I don't think that exact work
is very important here.


> But what happens to additional code, e.g.
>  <?* $str, 'html', 42 ?>
>  <?* $str, 'html'; echo 42 ?>
This is new operator with new syntax. It will give parsing error.


> Contrast that to the language specification which explains:
> | If <?= is used as the start-tag, the Engine proceeds as if the
> | statement-list started with echo statement.
> Simple, yet precise.

<?= '1'; echo '2' ?> which output '12' is simple? It does not seem clear
for me.


> I still don't see the benefit of being able to write
>  <?* $str ?>
> instead of
>  <?=h($str)?>

With new operator you cannot output unsafe value. It wiil be escaped or
will not be output.


> a few minutes ago, security updates for CVE-2016-2040 were published:
>
https://github.com/phpmyadmin/phpmyadmin/commit/edffb52884b09562490081c3b8666ef46c296418
>
https://github.com/phpmyadmin/phpmyadmin/commit/75a55824012406a08c4debf5ddb7ae41c32a7dbc
>
https://github.com/phpmyadmin/phpmyadmin/commit/aca42efa01917cc0fe8cfdb2927a6399ca1742f2

Good examples, thanks. This is what I'm trying to explain.


> It's not possible for multiple frameworks or libraries to declare
different escape handlers in your proposal, either.

It works similer to set_error_handler(). Is it poossible to declare
different error handlers? I think, yes.


> with <?=e()?> you have to define an e() function
Or just write without e(). I.e. you have not to.


> which is why I think it's bizarre that the current version doesn't even
have a built-in HTML escaper at all.
> This argument is only valid if the RFC includes an implementation, not
just a syntax.

Ok, if it will contain a default escape handler with a possibility to fully
unregister it and set custom one, will it be better variant? I will add an
additional voting about this option.

But:
> In my opinion, they are central to the feature, not an optional extra.
If user will want to use different flags for htmlspecialchars(), it will
anyway must unregister built-in handler.


> OK, so I can dynamically redefine the same syntax to mean different
things at different times, within the same application. I'm not entirely
sure that's a particularly good thing.

As I understand, you can do the same in Twig, setEscaper() function does
not perform any checks.
https://github.com/twigphp/Twig/blob/f0a4fa678465491947554f6687c5fca5e482f8ec/lib/Twig/Extension/Core.php#L29


> Then why is absolutely everything in the current RFC optional and
configurable to the Nth degree?
All that this RFC contains is just an escape handler. As we agreed,
customization is required.


> Frameworks are free to write all sorts of weird shit:
And? You can do the same in Twig. Is it a bad template engine?



Ok. Just ask you, why people ask the same question again since the time PHP
was created? Why almost all feature requests mentioned in RFC are about an
easy way to call htmlspecialchars()? You can vote up or down, I just want
to get an official result about this feature. I think, it can be considered
as official answer to community, to those people from community who would
like to use default escaping mechanism in PHP.

--94eb2c0566ce6c8058053889b10f--