<p dir="ltr">Without CDATA you have to encode script bodies properly.  With CDATA you have to encode script bodies properly.  What problem did CDATA solve?</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 28, 2016 8:03 PM, "Alexander Jones" <<a href="mailto:alex@weej.com">alex@weej.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They do solve the problem. You encode your entire JS *before* pasting it, encoding `]]>` and nothing more, and the XML document's text node contains the unadulterated text, which the JS parser also sees. It's perfect layer isolation. Ye olde HTML can't do that because there is no escaping mechanism for `</script>` that actually allows the JS parser to see the text (code) <span></span>content unmodified.<div><br><div>Viva la `<xhtml:revolución />` ;)<br><div><br>On Wednesday, 28 September 2016, Mike Samuel <<a href="mailto:mikesamuel@gmail.com" target="_blank">mikesamuel@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I agree it's subideal which is why I work to address problems like this in template systems but ad-hoc string concatenation happens and embeddable sub-languages provide defense-in-depth without sacrificing correctness.</p>
<p dir="ltr">CDATA sections solve no problems because they cannot contain any string that has "]]>" as a substring so you still have to s/\]\]>/]]>]]<!CDATA>/g.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 28, 2016 2:32 PM, "Alexander Jones" <<a>alex@weej.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's awful. As you say, it's an antipattern, no further effort should be spent on this. JSON produced by JavaScript has far more general uses than slapping directly into a script tag unencoded, so no-one else should have to see this. Also, there are many other producers of JSON than JavaScript.<div><br></div><div>Instead, use XHTML and CDATA (which has a straightforward encoding mechanism that doesn't ruin the parseability of the code or affect it in any way) if you really want to pull stunts like this.</div><div><br></div><div>Alex<span></span><br><div><br>On Wednesday, 28 September 2016, Michał Wadas <<a>michalwadas@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Idea: require implementations to stringify "</script>" as "<\uxxxxscript>". </p>
<p dir="ltr">Benefits: remove XSS vulnerability when injecting JSON as content of <script> tag (quite common antipattern). </p>
<p dir="ltr">Backward compatible: yes, unless binary equality is required and this string is used. </p>
</blockquote></div></div>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br></blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div>