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.vostri...@gmail.com>
napisał(a):
>
> >> 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.
