如何在 asp classic 中触发异步调用并忽略响应？
要点如下：
我想在 asp 中进行调用，并且我不关心响应。我只想触发呼叫，并且不希望页面等待响应。根据文档，它应该看起来像这样：
dim xmlhttp : set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.Open "POST", url, true '' setting the 'asynchronous' option to 'true'
xmlhttp.setRequestHeader "Content-Type", "application/soap+xml; charset=utf-8"
xmlhttp.setRequestHeader "Content-Length", Len(XMLData)
xmlhttp.send XMLData
同步调用时效果很好，但是当我将异步选项设置为“true”时，不会触发任何操作。我从互联网上可以收集到的是，用户会执行以下操作：
While xmlhttp.readyState <> 4
xmlhttp.waitForResponse 1000
Wend
我是否疯了，因为如果您正在等待响应，这看起来不再像异步调用了？
将 xmlhttp.waitForResponse 1 行放在发送之后将导致请求触发，但同样，我不想等待一秒钟。
有什么想法吗？
Here's the gist:
I have a call I want to make in asp, and I do not care about the response. I just want to fire the call and I do not want the page to wait for the response. According to the documentation, it should look something like this:
dim xmlhttp : set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.Open "POST", url, true '' setting the 'asynchronous' option to 'true'
xmlhttp.setRequestHeader "Content-Type", "application/soap+xml; charset=utf-8"
xmlhttp.setRequestHeader "Content-Length", Len(XMLData)
xmlhttp.send XMLData
This works peachy when calling synchronously, but when I flip the ansynchronous option to 'true', nothing fires. What I can gather from the internet is that users do something like the following:
While xmlhttp.readyState <> 4
xmlhttp.waitForResponse 1000
Wend
Am I crazy in that this does not really seem like an asynchrous call anymore though if you are waiting for a response?
putting the line xmlhttp.waitForResponse 1 right after the send will cause the request to fire, but again, I don't want to wait a second.
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
今天我遇到了同样的问题。
我通过使用“Microsoft.XMLHTTP”对象解决了这个问题。
现在请求是异步发送的并且目标 URL 被命中。
希望有帮助。
Today I got the same issue.
I resolved it by using "Microsoft.XMLHTTP" object.
And now the request is sent asynchronously and target URL was hit.
Hope that helps.
这里的关键问题是，如果您不等待并且脚本结束，则 ServerXMLHTTP 组件会自行销毁并在此过程中中止未完成的请求。您无法保证当时请求到达何处。
例如，如果您的服务器还没有抽出时间向目标服务器发出消息，它将发现不再需要它并且不会打扰。
即使已与目标服务器建立连接，请求也可能尚未发送给处理程序。通常，Web 服务器会在提交资源来满足请求之前检查客户端是否仍处于连接状态。如果它发现您的连接已断开，则不会费心完成请求。
换句话说，在经典 ASP 中没有可靠的方法来异步执行此操作，它只是不是为处理此类事情而设计的。最好的办法就是在脚本处理其他事情的同时做其他事情（如果您还有其他事情要做），但是，我什至不建议这样做，因为 ASP 内的异步 WinHTTP 很脆弱。
The key problem here is if you don't wait and your script ends the ServerXMLHTTP component destroys itself and in the process aborts the outstanding request. There is no way for you to guarantee where the request has got to at that time.
For example if your server hasn't got round to issuing to the destination server it will see that its no longer needed and not bother.
Even if a connection has been made to the destination server the request may not yet have been given to a handler. Often a web server will check that client is still connected before committing resources to fulfilling a request. If it sees your connection has been dropped it won't bother completing the request.
In other words there is no reliable way to perform this operation asychronously in classic ASP, it just isn't designed to handle that sort of thing. The best you can get is to do other stuff while your script gets on with something else (if you've got anything else to be getting on with), however, I wouldn't even recommend that since asynchronous WinHTTP inside ASP is flaky.
我们使用异步 XMLRequest 将错误记录到 ASP 站点中的 Fogbugz 中。由于它只是一个错误报告，我们不希望用户等待我们的代码完成，因此我们异步执行它。这可能是因为缺少配置文件、数据库超时、在某处配置文件中缺少查找等。并不总是关键的任务，但了解一下很重要。在这些情况下，异步工作是一种享受，如果不是，那么对我们来说这不是世界末日，但我们没有遇到任何问题。我们一直在使用我们创建并发布在另一个问题中的这个脚本：
经典 asp 中的 System.Net.HttpWebRequest？
就像 Anthony 所说的那样，尽管它不是 100% 保证能够通过。作为可能的修复，您可以设置 Response.Buffer = true，将所有输出呈现给用户，调用 Response.Flush，然后执行 waitForResponse 调用。用户将看到整个页面，并能够与它进行交互，而不会出现任何延迟，这让您的异步调用有更多的时间来完成。
We use async XMLRequest to log errors into Fogbugz in our ASP sites. As its only an error report we don't want our users hanging around waiting for our code to finish so we do it async. This could be for anything from a missing config file, DB timeout, missing lookup in a config file somewhere, etc. Not always mission crytical stuff but good to know about. In those cases the async works a treat and if not then its not the end of the world for us but we've not had any problems with it. We've been using this script which we create and posted in another question:
System.Net.HttpWebRequest in classic asp?
Like Anthony says though its not 100% guanenteed to get through. As a possible fix you could sert Response.Buffer = true, render out all your output to the user, call Response.Flush and then do a waitForResponse call. The user will see the whole page and be able to interact with it without any hold up and it gives your async call a bit more time to finish.
如果您仍然想使用 ServerXMLHTTP 对象（而不是 Anton 上面提到的客户端组件），请参阅常见问题解答 #4，网址为 http://support.microsoft.com/kb/290761) 是创建一个 VBScript 类。实例化该类。将类的属性设置为 HTTP 对象。然后调用一个方法来触发请求。
永远不要销毁类实例 - 当 ASP 页面完成时它会自动销毁。让类销毁方法释放 HTTP 对象 - 这应该给它足够的时间在销毁之前触发请求。
Another option if you still want to use the ServerXMLHTTP object (and not the client-side component mentioned above by Anton see FAQ #4 at http://support.microsoft.com/kb/290761) is to create a VBScript class. Instantiate the class. Set a property of the class to the HTTP object. Then call a method to fire off the request.
Don't ever destroy the class instance - it will be automatically destroyed when the ASP page finishes. Have the class destruction method free the HTTP object - that should give it enough time to fire off the request before it is destroyed.