If enough people do so, I can almost guarantee that the Adobe dev
staff will take notice, and look at including that or a similar
function in the next version of cf.
Based on experience with dealing with empty list elements in list
functions, it may take a long time ;-)
--
_New_ function, not a change (potentially breaking existing applications).
On Jan 2, 2008 3:05 AM, Claude Schneegans [EMAIL PROTECTED] wrote:
If enough people do so, I can almost guarantee that the Adobe dev
staff will take notice, and look at including that or a similar
function in the next
_New_ function, not a change (potentially breaking existing
applications).
nope... won't break any existing applications...
Honestly, I think I'm going to stop recommending people use
jsstringformat in general and recommend they use SerializeJSON for
string values instead...
--
s. isaac
If anyone really feels strongly about this, they should create a
function that does what they want, name it something more useful and
specific, and place it on cflib.org
function JSF(s) { return replacelist(s,,',/,\,\',\/); }
The problem isn't that it can't be done -- the problem is that
The problem isn't that it can't be done -- the problem is
that people (programmers) expect it to be bulletproof for a
common situation which it's not... it could be...
I don't know why on earth you'd expect it to be bulletproof for a common
situation, as opposed to behaving like every other
but there's some strange desire to not make it bulletproof
based on a fear of ambiguous problems that might arise from
fixing the specific problem that we know exists.
Yes! I'm much more afraid of ambiguous problems that might be caused
by a change, than I am by the ones I know how to
To completely cover the latter, if you need to emit a JS string
containing a literal /script within a HTML SCRIPT block, you
manually split it and you're done.
Still seems like duct tape-- but I agree that does seem to be the most
(and only?) appropriate way to handle it.
If you think
I think it is obvious that
/script is not a safe string under certain JavaScript conditions.
The problem is not with Javascript here, it is with the HTML parser.
The HTML parser considers that the JS code is only
alert('
and passes it to the JS engine. The engine does what it can with what it
If I enter the End of /script and it gets butchered when it goes
somewhere else, that's a bug.
If it's a bug, it is only in the CMS that did not make sure the HTML
code it produces was right.
Not in the HTML parser.
The HTML parser does not parse the Javascript code, so obviously,
the parser
This
has nothing to do with the safety of JavaScript string literals at all,
and everything to do with HTML.
Absolutely.
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any spam to this address:
In spite of the fact that SerializeJSON() handles it correctly.
That's a different function, designed to do a different thing. Your
comparison is analogous to complaning that XMLFormat doesn't behave
like CFWDDX.
That's one of the dumbest things I've ever heard in my life.
You
This
has nothing to do with the safety of JavaScript string literals at
all, and everything to do with HTML.
Absolutely.
Totally irrelevant.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 503.236.3691
http://onTap.riaforge.org/blog
If it's a bug, it is only in the CMS that did not make sure the HTML
code it produces was right. Not in the HTML parser. The HTML parser
does not parse the Javascript code, so obviously, the parser must rely
on its end tag /script to resume parsing HTML code. This imply that
by definition the
JSStringFormat, XMLFormat, URLEncodedFormat, HTMLCodeFormat, and
HTMLEditFormat take existing strings and remove any metacharacters
from them. They sanitize the string - make it safe - for the
specific target environment in which the string will be used. The
specific metacharacters in
Thanks for the remarks Claude. I do fully understand the mechanics
behind why the error occurs. I guess you could say my beef/confusion is
that:
-- For once, CF doesn't have a pre-built way escape something and it
seems odd. (Although, it has been called an edge case)
-- It is a rather sneaky
-- It is a rather sneaky gotcha' and no one seems to care-- Everyone
(almost) seems to be saying yeah, so what? That's TECHINCALLY right.
Which happens to be one of my biggest peeves... Like the guys who say
that javascript is technically correct when you ask it to perform 10/1
or some
Therefore, jsstringformat should format strings the way
SerializeJSON does.
I don't agree:
The purpose of jsstringformat is to make a string safe as a Javascript
string in a Javascript context, no more.
JSON is a text format that is completely language independent, not only
Javascript, but
I don't think it's a good idea for one of these functions to
guess that I want to remove something that isn't a metacharacter when in
fact I may not.
Exact.
Another good example is the MSHTML editor which absolutizes relative
link addresses
accordingly to the directory in which the editor is
Therefore, jsstringformat should format strings the way
SerializeJSON does.
I don't agree:
The purpose of jsstringformat is to make a string safe as a Javascript
string in a Javascript context, no more.
JSON is a text format that is completely language independent, not only
Javascript,
Then the context of jsstringformat should be widened.
Ok, then call it JSstringInHTMLformat. ;-)
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any spam to this address: [EMAIL PROTECTED])
If anyone really feels strongly about this, they should create a
function that does what they want, name it something more useful and
specific, and place it on cflib.org
Then put a note on the livedocs pointing to the new function.
Finally, watch and see how many people then go download the
I had always believed that jsstringformat did absolutely everything
necessary to string of text in order to set it into a JavaScript string
variable.
I realized last night I was wrong.
The following HTML example will error:
script LANGUAGE=JavaScript TYPE=text/javascript
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
:[EMAIL PROTECTED]
Sent: Monday, December 31, 2007 1:02 PM
To: CF-Talk
Subject: Re: Should jsstringformat do more?
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
I had always believed that jsstringformat did absolutely
everything necessary to string of text in order to set it
into a JavaScript string variable.
JSStringFormat escapes JavaScript metacharacters; nothing more, nothing
less. That's all it does, and that's all it's supposed to do.
The
So, do you consider that to be a browser bug or is the
replace method really the right way to do it?
I certainly wouldn't consider it a browser bug. The browser's job, first and
foremost, is to parse HTML. The closing SCRIPT tag is HTML. The browser
can't be expected to look at your closing
I had always believed that jsstringformat did absolutely
everything necessary to string of text in order to set it
into a JavaScript string variable.
JSStringFormat escapes JavaScript metacharacters; nothing more,
nothing
less. That's all it does, and that's all it's supposed to do.
The
My feeling would be no. I like the way it currently works.
JSStringFormat does what the function says. It is not called JSSafeFromAnything.
As you point out, it is only unsafe under certain conditions. So I am
glad it does not always strip everything out that might possibly meet
a seldom seen
The LiveDocs for CF7 simply state jsstringformat returns A
string that is safe to use with JavaScript.. I think it is
obvious that /script is not a safe string under certain
JavaScript conditions.
Ok, so technically, /script IS safe with JavaScript
alone-- but it isn't a safe string
The second example is irrelevant. If you have the same problem with a
JavaScript literal string in a static HTML page, the fact that you can
generate such a string - which, as you note, is in fact a valid
JavaScript
literal string - with CF doesn't make this a CF problem.
I would have to
I would have to disagree. I am not attempting to blame
ColdFusion for the behavior of my browser. I am charging the
documentation and behavior of the jsstringformat function to
be misleading (and possibly too narrow) given the fact that
it advertises safe strings. I figure the majority
Naturally your examples do not error since you have demonstrated a
JavaScript string containing the text /script which is not contained
within real script tags. My onus however, was not to prove that EVERY
arbitrary /script embedded within a JS string in an HTML document
would error but rather
To completely cover the latter, if you need to emit a JS string containing a
literal /script within a HTML SCRIPT block, you manually split it and
you're done. jsStringFormat will make ensure a CF string is safe for use as
a JS string, according to the rules of the JS language. It doesn't (and
Naturally your examples do not error since you have
demonstrated a JavaScript string containing the text
/script which is not contained within real script tags.
My onus however, was not to prove that EVERY arbitrary
/script embedded within a JS string in an HTML document
would error
I wrote that it was an edge case because you're the first person to have
both encountered this problem and to also have suggested that CF isn't doing
what it should.
Umm... nope, I mentioned this a few years ago. And had mentioned it on
a number of occasions since then. The fact that nobody
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
The LiveDocs for CF7 simply state jsstringformat returns A string
that is safe to use with JavaScript.. I think it is obvious that
/script is not a safe string under certain JavaScript
conditions.
Viola. It doesn't do what its documentation describes.
Who here wants to call it a
As you point out, it is only unsafe under certain conditions.
You mean any condition in which a user might have entered something into
a form?
As compared to:
What circumstance in which would it be a problem if it escaped the
/script string?
I can tell you what circumstance in which that
Yes, that's how the function should work. The behavior you want is an
edge case, and it's something you can easily do yourself with a
workaround. However, making that the default behavior would require
that CF know all of the things that could cause a JavaScript literal
string to cause
If I enter the End of /script and it
gets butchered when it goes somewhere
else, that's a bug.
Yes. A bug in your code. It is the job of your code to ensure that values are
used and stored appropriately.
Dave Watts, CTO, Fig Leaf Software
Umm... nope, I mentioned this a few
years ago.
OK, two people. Still an edge case.
Dave Watts, CTO, Fig Leaf Software
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
In spite of the fact that SerializeJSON()
handles it correctly.
That's a different function, designed to do a different thing. Your comparison
is analogous to complaning that XMLFormat doesn't behave like CFWDDX.
Dave Watts, CTO, Fig Leaf Software
On Dec 31, 2007 6:26 PM, s. isaac dealey [EMAIL PROTECTED] wrote:
As you point out, it is only unsafe under certain conditions.
What circumstance in which would it be a problem if it escaped the
/script string?
I can tell you what circumstance in which that would happen -- NEVER.
Whether
Looking at what GMail did to the formatting, I've posted the raw source here:
http://barneyb.com/rhino/jsstringformat.txt
cheers,
barneyb
On Dec 31, 2007 7:26 PM, Barney Boisvert [EMAIL PROTECTED] wrote:
On Dec 31, 2007 6:26 PM, s. isaac dealey [EMAIL PROTECTED] wrote:
As you point out, it
In spite of the fact that SerializeJSON()
handles it correctly.
That's a different function, designed to do a different thing. Your
comparison is analogous to complaning that XMLFormat doesn't behave
like CFWDDX.
That's one of the dumbest things I've ever heard in my life.
--
s.
Whether it would be NEVER or not, the simple fact is that it's
IMPOSSIBLE for CF to do this. The only way I can think to do it
would be as a postprocessing of the entire generated content (an
outbound servlet filter) with a full HTML and JS parser available.
Here's a relatively simple
46 matches
Mail list logo
