5 ms·
This feels an awful lot like we're going full PHP[1]. Can't this just remain as a library someone else could implement? [1]: https://www.php.net/manual/en/filt
by prussian 5y ago
This feels an awful lot like we're going full PHP[1]. Can't this just remain as a library someone else could implement?
[1]: https://www.php.net/manual/en/filter.filters.sanitize.php https://www.php.net/manual/en/filter.filters.sanitize.php
- jpalomaki 5y agoIf it’s part of browser, then it’s likely up-to-date with the latest features and quirks of the browser.
- slver 5y agoIs "PHP had something like this once" your only argument?
- prussian 5y agoGiven I've seen some CMS's double escape html character entities and other such bad uses of sanitation filters, I think it is a reasonable concern to think about. Forcing people to source a library would make it clear what their intent is in terms of cleaning things up.
- Hjfrf 5y agoConsidering the history of mysql_escape_string it's an important argument
- slver 5y agoThis is from MySQLs C library.
- deleted 5y ago[deleted]
- detaro 5y agoSee the spec document for the rationale. In short: The browser already has a good and safe parser, and knows best how it will treat which elements. An external parser written in JS is overhead while likely to be worse than/outdated compared to the browser. (In general security practices, parsers being used for validation being different than the parser used for processing later is somewhat of a smell, because it makes it more likely you can sneak something bad through a special case)