Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEDdnaVx2Rx0pe+ZCzP=rpWW8OiQ73opmRhLCho_MwV1NRAiaw@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>
	<CAEDdnaVx2Rx0pe+ZCzP=rpWW8OiQ73opmRhLCho_MwV1NRAiaw@mail.gmail.com>
Date: Tue, 26 Jul 2016 16:58:01 +0200
Message-ID: <CABdc3Wo_=M+zLcK2YxpTNCkSPLrBYHuxCr_vYYNfnzhRpxXwgw@mail.gmail.com>
To: Michael Vostrikov <michael.vostrikov@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1145beb093fda505388b204d
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a1145beb093fda505388b204d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Previously you wrote about PHP as a lang only. There was an RFC
https://wiki.php.net/rfc/script_only_include about dissallow opening tags
in require statements - personally I'd love to see it in PHP it could
minimize affect af featores like operator we're talking about to just
templates.

26 lip 2016 15:16 "Michael Vostrikov" <michael.vostrikov@gmail.com>
napisa=C5=82(a):
>
> >> if ($context =3D=3D 'html') {
> > this is bad coding style since $context =3D 0 gives unexpected html
> escaping.
>
> I know, it was just an example)
>
>
> > The RFC speaks of *operator*, where actually start-tags[1] are meant, t=
o
> 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 <?=3D is used as the start-tag, the Engine proceeds as if the
> > | statement-list started with echo statement.
> > Simple, yet precise.
>
> <?=3D '1'; echo '2' ?> which output '12' is simple? It does not seem clea=
r
> for me.
>
>
> > I still don't see the benefit of being able to write
> >  <?* $str ?>
> > instead of
> >  <?=3Dh($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/edffb52884b09562490081c3b86=
66ef46c296418
> >
>
https://github.com/phpmyadmin/phpmyadmin/commit/75a55824012406a08c4debf5ddb=
7ae41c32a7dbc
> >
>
https://github.com/phpmyadmin/phpmyadmin/commit/aca42efa01917cc0fe8cfdb2927=
a6399ca1742f2
>
> 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 <?=3De()?> 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 a=
n
> 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/f0a4fa678465491947554f6687c5fca5e482f8=
ec/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 a=
n
> 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.

--001a1145beb093fda505388b204d--