"<>&" in script xexprs

[Byron Davies]

In strings, xexpr->xml converts "<>&” into &lt;, etc. I’m sure this was well-intentioned, but in my use of web-server, I use javascript scripts through the (script “…”) form. In loop tests such as “i < n”, Javascript does not grok the transformed text “i &lt; n”. I tried workarounds for as long as I could (e.g, using the “for key in lst” style of loops), but I reached the end of the line when I wanted to change the contents of a table cell using “cell.innerHTML = ‘<div …>’.

But now I have to ask, is there a good way to make this change? In …xml/private/writer.rkt there’s this:

(define escape-table #px"[<>&]”)

Would it make sense to rebind escape-table while inside a (script …) element, or would this screw up something else?

Byron

[Jon Zeppieri]

I haven't tried this, but I think that script source should be in a
cdata structure
[http://docs.racket-lang.org/xml/index.html?q=xexpr#%28def._%28%28lib._xml%2Fmain..rkt%29._cdata%29%29]
to prevent the behavior you're seeing. -J

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matthew Butterick]

On Sep 19, 2017, at 1:36 PM, Byron Davies <byron...@starshine.us> wrote:

In strings, xexpr->xml converts "<>&” into &lt;, etc. I’m sure this was well-intentioned, but in my use of web-server, I use javascript scripts through the (script “…”) form.  In loop tests such as “i < n”, Javascript does not grok the transformed text “i &lt; n”.  I tried workarounds for as long as I could (e.g, using the “for key in lst” style of loops), but I reached the end of the line when I wanted to change the contents of a table cell using “cell.innerHTML = ‘<div …>’.

HTML ≠ XML. You probably want `xexpr->html`. [1]

`script` and `style` blocks in HTML aren't declared as CDATA because they're already deemed to be CDATA. [2] 

But in XML, they have no special status. Therefore, `xexpr->xml` is not merely "well-intentioned" — it's doing what it promises. 

[1] https://docs.racket-lang.org/txexpr/index.html?q=txexpr#%28def._%28%28lib._txexpr%2Fmain..rkt%29._xexpr-~3ehtml%29%29

[2] https://www.w3.org/TR/html4/types.html#h-6.2

[Byron Davies]

Thank you for highlighting cdata. That’s an important clue. Now I know to wrap my javascript strings in a cdata structure/form.

[Byron Davies]

Right.  My understanding increases bit by bit.

I’m using response/xexpr, which — unlike your xexpr->html — doesn’t special-case script and style tags. Funny, I had read through your txexpr docs, but the special-casing of script and style didn’t jump out at me at the time, and I had forgotten it by the time I needed it.

cdata it is.  Thanks to people like you, Racket does what I need, as usual. The problem is I don’t always know what I need.

[Matthew Butterick]

On Sep 19, 2017, at 5:38 PM, Byron Davies <byron...@starshine.us> wrote:

Right.  My understanding increases bit by bit.

I’m using response/xexpr, which — unlike your xexpr->html — doesn’t special-case script and style tags. Funny, I had read through your txexpr docs, but the special-casing of script and style didn’t jump out at me at the time, and I had forgotten it by the time I needed it.

Ah yes, so it does. 

As default behavior of `response/xexpr`, that seems somewhere between iffy and wrong. There's a mismatch between its default mime-type of "text/html", and its use of `xexpr->string`, which produces XML, not the promised HTML. 

IIRC this mime-spoofing technique was used the early oughts to fool browsers into accepting XHTML. [1] But it's since been deprecated. [2]

[1] https://www.w3.org/MarkUp/2004/xhtml-faq#texthtml

[2] https://hixie.ch/advocacy/xhtml (search for heading "Why trying to use XHTML and then sending it as text/html is bad")