How is javascript evaluated at the target page in an AJAX situation?

Question

This may be a philosophical question.

Suppose you're making an AJAX request to a page (this is using Prototype):

new Ajax.Request('target.asp',
{
 method:"post",
 parameters:{alldata:Object.toJSON(myinfo)},
 onSuccess: function(transport){
   var response = transport.responseText || "no response text";
   alert("Success! \n\n" + response);
   },
 onFailure: function(){ alert('Something went wrong...') }
});

Now suppose on the target page, the server -- using ASP -- generates some Javascript based on the myinfo object you sent it, and you are interested in the resulting Javscript. My guess is that, since this target page is never seen by a browser (where the JS interpreter lives), the JS isn't evaluated. And it will only be evaluated if it is returned to the calling page and evaluated there. Is that the point?

Thanks for screwing my head on straight for me.

Answer 1

The JS on the target.asp page is not evaluated in the client unless you eval() it or push it into the DOM or something.

Answer 2

Yes, the assumption is right. The response of that Ajax request is just a string. And that needs to be interpreted somehow that the JavaScript that’s embedded in that response is also interpreted.

Answer 3

I am not at all comfortable with ASP, I'll say that up front...

If the server is generating javascript, it would be as a string. As such, it would need to be written to the DOM in some way in order to be meaningful (I'm including the ajax script when I say DOM).

BUT!!!

I know that ASP and .NET are really weird and like to put hooks and callbacks all over the place. In theory, ASP does speak javascript and thus might have some js interpreter of it's own. But I try to sleep at night by thinking that the folks at MS would NOT allow their server-side scripts to execute anything that is intended for the client-side.

Short answer: yes, if the code isn't written out to the page, the code shouldn't be executed. You should be encoding your server's output to be on the safe side, simply because it's a good practice (changing < to <, etc).