> It shouldn't do that. It formats a string, and all of those
> characters are valid characters within a JS string. You wouldn't want
> to do anything special if you were serving a JS file out to the
> browser; it's only when you're serving JS embedded in an HTML file
> that you need to worry about </script> tags in the strings. So it's a
> response assembly problem, not a string formatting problem.
Not true.
You run a ezine and you ask me to write an article. I title my article
"the End of </script>" and enter it into the form. The title of articles
is known to be an atomic value, so whatever I enter in that field,
should show up *exactly* that way, no matter where it's output, and
regardless of what I chose to put in it. I could title my article
"</script></script></script></script>nnn... blah blah I'm the king of
France" - it doesn't matter, because it's a literal, atomic value. If I
enter "the End of </script>" and it gets butchered when it goes
somewhere else, that's a bug.
FURTHER
SerializeJSON actually *does* format those strings properly in a way
that doesn't break. CFWDDX on the other hand does not.
And given that we're talking about a trivial change, it doesn't make any
sense at all to push back and say "oh no, it's supposed to have that
limitation."
</rant>
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;160198600;22374440;w
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:295620
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
