rfc:escaping_operator

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:escaping_operator [2016/07/30 14:09] – michael-vostrikovrfc:escaping_operator [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== PHP RFC: New operator for context-dependent escaping ======+====== PHP RFC: New operator (short tag) for context-dependent escaping ======
   * Version: 1.0   * Version: 1.0
   * Date: 2016-07-14   * Date: 2016-07-14
   * Author: Michael Vostrikov <michael.vostrikov@gmail.com>   * Author: Michael Vostrikov <michael.vostrikov@gmail.com>
-  * Status: Under Discussion+  * Status: Declined
   * First Published at: http://wiki.php.net/rfc/escaping_operator   * First Published at: http://wiki.php.net/rfc/escaping_operator
  
Line 22: Line 22:
  
 The problem is that <php><?= h($something) ?></php> and <php><?= $something ?></php> both work good, and unsafe variant works exactly as safe one until we get unsafe data. 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 will break the script, and this will be noticeable, there won't be a problem with security. Also, because we need to call escaping function everywhere, the problem is that we must copy-paste it, and there is a possibility to forget to do this sometime. The problem is that <php><?= h($something) ?></php> and <php><?= $something ?></php> both work good, and unsafe variant works exactly as safe one until we get unsafe data. 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 will break the script, and this will be noticeable, there won't be a problem with security. Also, because we need to call escaping function everywhere, the problem is that we must copy-paste it, and there is a possibility to forget to do this sometime.
 +
 +Calling an escaping function manually on every output is the same as calling constructor manually after every 'new' statement:
 +<PHP>
 +(new User)->__construct(...);
 +(new Profile)->__construct(...);
 +</PHP>
  
 Main argument against such operator is that main problem is in specific context. There are various contexts and each one requires special escaping. But I think this is not required to support all of them. Because - who asks about it?) There are no requests about special operator for json_encode(), but there are many requests for htmlspecialchars(). You can not deny the problem with HTML escaping really exists. My first goal is to draw the attention on it. Exact implementation is a secondary thing. Main argument against such operator is that main problem is in specific context. There are various contexts and each one requires special escaping. But I think this is not required to support all of them. Because - who asks about it?) There are no requests about special operator for json_encode(), but there are many requests for htmlspecialchars(). You can not deny the problem with HTML escaping really exists. My first goal is to draw the attention on it. Exact implementation is a secondary thing.
Line 232: Line 238:
 It is easy to use and has small amount of code. It is easy to use and has small amount of code.
 It does not change Zend VM opcodes and does not break any existing code. It does not change Zend VM opcodes and does not break any existing code.
 +It can be used as a replacement for standard '<?= $str ?>' operator in the form like '<?* $str, 'raw' ?>'.
  
 Also it will be useful for beginners, which don't know about HTML escaping or forget about it. If there will be special operator for HTML-safe output, beginners will use it, because this is simple. Also it will be useful for beginners, which don't know about HTML escaping or forget about it. If there will be special operator for HTML-safe output, beginners will use it, because this is simple.
Line 323: Line 330:
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
  
-Can this operator be useful for many people and implemented in PHP in some of forms described above?\\ 
-The choices are Yes or No\\ 
 Requires a 2/3 majority\\ Requires a 2/3 majority\\
 +Voting is open till August 6.\\ 
  
 +Will this short tag / operator be useful for many people with the functionality described above?
 +<doodle title="Add new operator (short tag) for context-dependent escaping to next PHP 7.x?" auth="michael-vostrikov" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
 +\\ 
 +Additional questions. Voting is not required if you have voted 'No' in the first vote.
 +\\ 
 +<doodle title="Is default handler required, with a possibility to fully unregister it?" auth="michael-vostrikov" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +\\ 
 +
 +<doodle title="Is it needed to wrap the functions into static class?" auth="michael-vostrikov" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +\\ 
 +
 +<doodle title="Is the comma suitable as a separation sign?" auth="michael-vostrikov" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +\\ 
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
 +
 Diff with changes:\\ Diff with changes:\\
 https://github.com/michael-vostrikov/php-src/commit/ca149a3dfea71f529eb1647f2d0ed2b8d63e279d https://github.com/michael-vostrikov/php-src/commit/ca149a3dfea71f529eb1647f2d0ed2b8d63e279d
rfc/escaping_operator.1469887747.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools