Update: the solution discussed below is generating CORS errors in JavaScript. Long story short, you need to allow CORS in IIS.

While VBScript is equipped with asynchronous components (httprequests, shell), when using them in ASP they're always synchronous. Classic ASP does not support asynchronous calls whatsoever. Classic ASP follows a strict set of sequences, which means that operations are performed one at a time, in perfect order, top to bottom.

Why would you need or use async calls in ASP? Imagine you want to run a véry long process after clicking a button: generate 10000 documents, or send out 10000 emails... This is not something you want the visitor to wait for. These things can take many hours.

There is a way around this limitation though. The solution: AJAX calls. Rather than perform async calls serverside, you can let AJAX do the job. AJAX calls are always asynchronous. The browser will never wait for an AJAX call to finish when loading or browsing away from pages.

However... Imagine you're browsing www.quickersite.com. You click a button that loads www.quickersite.com/ajax through AJAX. If www.quickersite.com/ajax takes 10 minutes to finish, your browser will wait 10 minutes before you'll be able to further browse www.quickersite.com. This is not what we want. We somehow shift the problem from the server to the browser.

There is a way around this. Instead of loading www.quickersite.com/ajax, you can load ajax.quickersite.com. Browsers assume that www.quickersite.com and ajax.quickersite.com are two different websites. Loading ajax.quickersite.com will not block visitors on www.quickersite.com whatsoever. Problem solved.

Be careful though. When calling ajax.quickersite.com, you cannot rely on the cookies/sessions/application/security you have on www.quickersite.com. You have to program your way around that shortcoming by making sure there are no security-risks when loading external urls. You may need passwords or tokens to ensure that urls load only once, or load only under specific circumstances.

There is another thing to keep in mind when using ASP for long processes, like sending out 10000 emails. Make sure to set Server.ScriptTimeout to a large number (default is 90 seconds). There is no (documented) maximum value. You may want to set it to 10800 in specific circumstances, allowing an ASP page script to run for 3 hours.

The bigger issue is though: is it a good idea to let an ASP page run, unattended, unmonitored, disconnected from the browser...  for hours? Maybe not... or maybe not always. ASP pages are not designed to run eternally, that's for sure. IIS can - at any time - reload applications, be reset, or simply crash a site when it eats too much memory, just to name something. In some cases though, where pages are running for few minutes only - or do not need loads of memory -  this is a legitimate workaround. I have used this technique several times with success.