Re: [RFC] New operator for context-dependent escaping

On 22/07/2016 16:54, Michael Vostrikov wrote:

The more you compare it to a function call, the less I understand how it

gains over just defining a function e() and writing <?= e( $foo, 'html') ?>

I might as well just write "function e($string, $mode='html') { .... }" they will already have a method of doing this

Yes, and they have to write a call of it everywhere. New operator can remove it. I told about it in previous messages, when explained why function autoloading is another problem - this is not a problem to create a function, the problem is to copy-paste it in 90% places of output data. The goal is to remove copy-paste for HTML escaping (so it will become automatic) and possible XSS when this copy-paste is missed. If we can get a work with other contexts, it will be just a good addition. I missed that from the rfc. I'm conflicted with this one. For you php "More than 90% of output data - is data from DB and must be HTML-encoded."

I have no idea how you came with this, even with applications or websites I'm working on not using a template engine this is far from the truth. especially now that more ans more web application are consuming json API, the backend often produce mostly json & xml. at that you can add csv and pdf sometimes used for reporting, invoicing, etc. then there is js ads so, if I'm used to only using <?* $data ?> for html, what will make me think about setting the different context on other places ? I'll probably end up with html encoded data in my csv files instead.

If you can pass a variable as the escaping method

Second variable is not escaping method. It is a context. Escaping function can handle this context as it wants.

On the other hand, if I have an array and ask for it to be HTML-escaped,

nothing iterates the array for me, it will just print "Array". So if I ask for it to be "JS-escaped", why should it magically produce a JSON array? Yes, I agree, I methioned this in RFC - JSON is not escaping, it is encoding in special notation. This is one of the reasons why I was disagreed with the need to support multiple contexts. So, the question is up again - do we really need multiple contexts? I don't think "json" escaping should produce an array, the escape should be on the output, if I have <?= [] ?> the output is Array if I have <?* [], 'json' ?> the output should be "Array"

I don't get why it's not escaping for you, if I have a template for a js file, I think I should be able to escape data like that: console.log(<?* $row['data'], 'json' ?>); what is the difference with html here ? the escape mechanism only works on string. obviously if I want to output a json object I should manually call <?= json_encode(['data' => $row['data']) ?> and finally I'll say it again, if I want to output a javascript string inside a script tag in a html file, for me that's two nested contexts and the escaping should not be different from one and the other

Again, focusing on simplicity: <?php set_escape_handler('html', 'htmlspecialchars'); set_escape_handler('json', 'json_encode'); ?> <?*html*json= $foo ?> becomes: <?php echo htmlspecialchars(json_encode($foo)); ?>

Yes, PHPEscaper from RFC works that way - PHPEscaper::registerHandler(). But it think runtime definition with second variable is more flexible way. There are external contexts (HTML is one of) and internal task-dependent contexts which can be combined with HTML. We cannot know all possible tasks. And we come again to pipe operator and twig-like syntax.

Which begs the question, if you can verify that the call to

set_escape_handler comes before the template, then can you also be sure that a function definition will come before it, and just call a function directly? Sorry, not sure if I understand your question. What do you mean in 'call a function directly'? If you mean <?= $this->escape($myValue, $myContext) ?> then the goal is to remove this copy-paste.