> > 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 kno
> 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 ot
> 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
> _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 d
_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 th
>>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 ;-)
--
__
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 funct
>>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])
Thank
> >>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
> Ja
>>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, but al
> -- 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 s
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
> 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 q
> 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 to resume parsing HTML code. This imply that
> by definition the JS
> >>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
~~~
> > > 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 l
>>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
>>If I enter "the End of " 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 must r
>>I think it is obvious that
"" 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
get
> To completely cover the latter, if you need to emit a JS string
containing > a literal "" 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 ther
> 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 e
> > 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.
--
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 o
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
> string?
>
> I can tell you what circumstance in which that would happen -- NEVER.
Whether
> 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
~~
> 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
> If I enter "the End of " 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
~
> 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 pr
> 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
string?
I can tell you what circumstance in which that would ha
> The LiveDocs for CF7 simply state jsstringformat returns "A string
> that is safe to use with JavaScript.". I think it is obvious that
> "" 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 document
> 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 abo
> 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
> Naturally your examples do not error since you have
> demonstrated a JavaScript string containing the text
> "" which is not contained within "real" script tags.
> My onus however, was not to prove that EVERY arbitrary
> "" embedded within a JS string in an HTML document
> would error but r
To completely cover the latter, if you need to emit a JS string containing a
literal "" 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
can't)
Naturally your examples do not error since you have demonstrated a
JavaScript string containing the text "" which is not contained
within "real" script tags. My onus however, was not to prove that EVERY
arbitrary "" embedded within a JS string in an HTML document
would error but rather the possibi
> 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 ma
> 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 d
> The LiveDocs for CF7 simply state jsstringformat returns "A
> string that is safe to use with JavaScript.". I think it is
> obvious that "" is not a "safe" string under certain
> JavaScript conditions.
>
> Ok, so technically, "" IS safe with JavaScript
> alone-- but it isn't a "safe" string
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 con
>> 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.
> 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
oisvert [mailto:[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 y
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
tags i
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:
alert('');
Even though the text "" is a perfectly es
46 matches
Mail list logo
