W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] base64 entities

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Thu, 26 Aug 2010 16:56:12 -0400
Message-ID: <AANLkTi=RSycCv_q9_S4niDj_9L15TmGPWyCMhxTYZb1+@mail.gmail.com>
On Thu, Aug 26, 2010 at 4:20 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> I have to admit that I'm not sure what's special about <script> here. Are
> you saying that it's insufficient to escape all characters that have a
> special meaning there?

data:text/html,<!doctype html>

alerts "&amp;", not "&".  So generally, you just don't escape stuff in
<script>, but I don't know of any general-purpose way to have
"</string>" in a string literal (or anywhere else), other than
splitting it up like "</scr" + "ipt>".

On Thu, Aug 26, 2010 at 4:25 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Sorta. ?It'll let you put the data in <script>, but it won't verify that the
> data doesn't change the meaning of the script, obviously, or inject script
> of its own to run.

Hmm.  Okay, then I don't get how this helps in Adam's second example:

elmt.innerHTML = 'Hi there <?php echo htmlspecialchars($name) ?>.';

If it doesn't help there, then I don't see any use-cases, since the
first example is trivially solvable by just using quotes.

>> Is automated general escaping even possible right now in<script> ?for
>> text/html?
> Defined how?

Suppose I have some arbitrary blob of trusted JavaScript, and I want
to output it as an inline script in text/html.  How do I escape it so
that it executes as intended -- in particular, given that it might
contain the string "</script>" in string literals, comments, and so
on?  In most contexts, you could just replace '<' => '&lt;', but that
doesn't work in inline <script>.

(Right?  I admit I'm mostly cargo-culting this, and have no idea how
text/html parsing works at all.  I have fond dreams of an HTML
serialization that's actually comprehensible to authors but has
reasonable error handling . . .)
Received on Thursday, 26 August 2010 13:56:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC