> That's all nice & dandy for json. But the "javascript getting executed
> solely on server saying so" problem still remains. The fact you had to
> change the synchronous request tests is a clear proof of the problem to me:
> existing code will break (no issue if documented), existing code will fac
That's all nice & dandy for json. But the "javascript getting executed
solely on server saying so" problem still remains. The fact you had to
change the synchronous request tests is a clear proof of the problem to me:
existing code will break (no issue if documented), existing code will face a
secu
Since we're going to be using JSON.parse, which throws an exception
(and triggers the Ajax error handler) it should probably be consistent
across platforms. I backported some syntax-checking logic from
json2.js and now throw an exception if it doesn't look like it's
proper JSON (which prevents atte
On Thu, Jan 7, 2010 at 11:04 AM, Douglas Crockford
wrote:
> I strongly recommend that you not compromise on safer.
Unfortunately we're in the very challenging position now where
introducing the use of window.JSON will absolutely break some
jQuery-using applications - and will continue to do so fa
What I'm worried about is attacks on existing pages.
So far, in jQuery, executing javascript was borded to conscious actions by
devs:
- inserting HTML in the document (ajax doesn't execute embedded script
automagically),
- jsonp,
- specific ajax wrappers (getScript, load) or cross-domain access to
> btw, I also saw you landed an auto-fetching for script (FYI, I
> "synchronized" the rewrite with latest changes, including javascript
> auto-execution) but I believe it is just plain wrong to let the server
> decide of what should be executed client-side (especially with cross-domain
> xhr gettin
I'll quote what I said in the $.ajax "auto" discussion (see last 2
paragraphs especially):
> > There's something significant behind the buzz, though. I really don't
> want
> > to read the announcement: "ATTN everyone using jQuery.ajax(). If you're
> > going to update your library or if you're link
We already support non-standard JSON strings since that's what we've
always supported. We do so by putting a try/catch around the
JSON.parse and falling back to the new Function technique, if an
exception is thrown.
Fundamentally though, using JSON.parse is faster and safer (although,
if we use th
