We Keep Coding

Request external domain and not care about the response content without using cors or proxy or anything outside of javascript

So a couple of days ago i was looking for something like this and had actually found it but never found a use for it. I know its listed somewhere on mozilla's site but i forget what the function is called.
In anycase i wish to request an external domain that doesn't have cors and does not requir external help from things like proxy's. its a rather recent function added to javascript as when i read about it (before i forgot the name) it was listed as expiremental technology. It's supposedly a safe alternative to CORS the only catch is unlike cors you are not allowed to view the response.
What i want to use it for is to basically see if the status code returned is 404 or 200 so i can tell users whether a specific site is having issues and since the ammount of sites that would be requested is huge if i do it server side id prefer to have it done in a clients browser only on specific pages.

I think you could get by with sending a HEAD HTTP request.

Why is cross domain AJAX prevented *if* you have no intention of evaluating the response as a script?

Let's say I want to use AJAX to retrieve a json file from an untrusted different domain.
I then parse the response as a javascript object without any script evaluation.
(A cookie is not sent with my request.)
I don't understand why the browser prevents me from doing this.
I understand that if I were to evaluate the response as a script then that would be a security issue.
I understand that there are work-arounds to achieve the above.
Is there a reason that my specific scenario should be prevented, or has it just got accidentally caught up in the same-origin dragnet?
Thanks.
(assuming the server does not support CORS)

... you have no intention of evaluating the response as a script?
Firstly, browser security has no way of determining what you intend to do.
Second, the same source / origin restrictions are designed prevent other things as well: e.g. see
http://blogs.msdn.com/b/ieinternals/archive/2009/08/28/explaining-same-origin-policy-part-1-deny-read.aspx

Cross-domain AJAX is possible, but the remote server needs to support CORS and there may be certain header restrictions.
JSONP is not necessary for most applications. If the remote server does not support CORS, then you're stuck with the same-origin garbage and you'll have to use JSONP.
Note:
Older browsers don't support CORS. You may want to use jQuery or a similar framework (I've had trouble with Mootools and cross-domain AJAX because I couldn't figure out how to remove some of the default headers. jQuery worked out of the box for me on my set-up.

Call JavaScript function from remote server

I tried to call JavaScript function exist on some server(server1) from another server(server2) and I got this error:
Unsafe JavaScript attempt to access frame with URL https://server1/ from frame with URL https://server2/ . Domains, protocols and ports must match.
I used JSP, Java, JavaScript and tomcat7, is there any way to solve this problem? any help will be appreciated.

Yes, must add a cross-origin rule to the header of your javascript file, which allows access from your other server.
Otherwise, your Browser doesn´t let you do that.
You can look at the answer of this Question: XmlHttpRequest error: Origin null is not allowed by Access-Control-Allow-Origin
It should tell you how to do it.

Take a look at easyXDM - it provides an RPC feature allowing you to call methods across the Same Origin Policy.
Take a look at one of the demo's here

As described you are subject to the Same Origin Policy, this is designed to protect users.
Google have a good write-up: http://code.google.com/p/browsersec/wiki/Part2.
There are several typical approaches to working around this:
jquery has a getJson or jsonp type of function. most other js libs have something similar. They use a dynamic Script tag, suitable for GET requests from other domains.
Create a servlet on domain1 that proxies to domain2 - allows unrestricted HTTP methods and use of XmlHTTPRequest.
I've not tried http://easyxdm.net/wp/
There are improvements coming, like cross document messaging in HTML5

Have someone modify javascript code without write access

I would like to test out some interviewees by having them write some javascript that will make requests against my server. I don't want to give them write access to my code base. Javascript runs on the client side, so this should technically be possible. However I know there are browser restrictions that say that the javascript has to come from the server?
I apologize that this is a really dumb question, but how should I proceed?
Edit:::
Ok, so I failed to mention that the entire application is based off sending JSON objects to and from the server.

I think you're thinking of the javascript XMLHttpRequest object itself, in which case, yes the current standard is for browsers to block cross-domain calls. So, you can tell them to pretend they either have a separate proxy script on their own personal domain which will allow them to leap to yours, or to pretend they're building a page directly served from your domain. There's talk of browsers supporting trust certificates or honoring special setups between source and target servers, but nothing universally accepted AFAIK.
Javascript source itself does not need to come from the server, and in fact this is how you can get around this little XMLHttpRequest block by using json. Here's a simple json tutorial I just dug up from Yahoo. But, this calls for your server to provide a json format feed if your server is the intended target.

"there are browser restrictions that say that the javascript has to come from the server"
I'm not aware of any situation where that's the case, only a lack of a console. But...even in those cases there's the address bar and javascript:.
If I misunderstood and you're talking about cross-domain restrictions, then your server needs to support JSONP for the requests so they can make cross-domain calls for data.

You could POST the javascript to your server and then your server can send back some HTML that has the javascript inlined. Sounds like you're trying to set up something is, more or less, a homebrew version of http://jsfiddle.net/; AFAIK, jsfiddle just does a "POST javascript/CSS/HTML and return HTML".

Suppressing browser's authentication dialog

I apologize that there is a similar question already but I'd like to ask it more broadly.
Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?
Or, is there any way at all to load an mp3 audio resource in flash which fails invisibly in the case of a 401 status code rather than letting the browser show an ugly dialog?
The Adobe Air run-time will suppress the authentication if I set the "authenticate" property of the URLRequest object but this property is not in the Flash run-time. Any solution which works on the client will do. An XMLHttpRequest is not likely to work as the resources in questions will be at different domains.
It is important to fail invisibly because the application will have a list of many audio resources to try and it makes no sense to bother the user to try and authenticate for one when there are many others available. It is important that the solution work on the client because the mp3's in question come from various servers outside my control.

I'm having the same problem with the twitter api - any protected user requires the client to authenticate.
The only solution that I could come up with was to load the pages serverside and return a list of the urls with their http response code.

"Is there any way at all to determine on the client side of a web application if requesting a resource will return a 401 status code and cause the browser to display an ugly authentication dialog?"
No, not in general. The 401 response is the only standard way for the server to indicate that authentication is necessary.

Just wrap your access to the resource that might potentially require authentication to an Ajax call. You can catch the response code, and use javascript to do whatever you want (ie. play that sound). If the response code is however alright, then use javascript to forward user to the resource.
Most likely this approach will generate slightly more load on server (you might have to resort to loading the same resource several times in some circumstances), but it should work. Any good tutorial about how to use XMLHttpRequest should contain all you need. Take a look at for instance http://www.xul.fr/en-xml-ajax.html

If you are using URLRequest to get the files, then you are running across more than just elegant error handling, you are running into a fundamental difference in the Flash and AIR run-times.
If using the URLRequest object to retrieve files you are going to get a security error from Flash on every request to every server that has not set a policy file to allow these sort of requests. AIR allows these requests since it basically IS the client. This makes sense since it's the difference between installing an application and visiting a web page.
I hate to provide the non-answer, but if you can't make a server-side call, and you are hitting a range of "not-known" servers, it's going to be a tough road to hoe.
But maybe I misunderstand, are you just trying to Link to the files and prevent the user from getting bad links, or are you trying to actually load the files?