即使服务器使用 SOAP 消息进行响应，Microsoft.Web.Services2.SoapClient.SendRequestResponse 也会超时
据我了解，发布您学到的一些有用信息的最佳方法是自己提出问题然后回答，所以就这样。
场景：
- 我们有一个应用程序，它从模板 xslt 文件构建 SOAP 请求，并添加一些参数，包括
- 它像请求一样访问的真实服务的 MessageID，愉快地响应，并且我们的客户端愉快地处理
- 我们正在尝试的 响应构建一个模拟服务
- 存根的存根/响应程序，仅实现 IHttpHandler 并响应任何 POST 操作
- 存根从 XML 文件读取预设响应（这是真实响应的示例），然后通过网络发送
- 它Visual Round Trip Analyzer（底层的 NetMon）和 Fiddler 看到通过线路传输到客户端的响应
- SendRequestResponse 最终超时并引发异常
As I understand it, the best way to post some useful info you've learned is to ask the question yourself and then answer it, so here goes.
The scenario:
- we have an app that contructs a SOAP request from a template xslt file and subs in a few parameters, including the MessageID
- the real service it accesses like the requests, responds happily and our client processes the response happily
- we're trying to build a stub/responder that simulates the service
- stub just implements IHttpHandler and responds to any POST operation
- stub reads a canned response, which is an example of a real response, from an XML file and sends it over the wire
- both Visual Round Trip Analyzer (NetMon under the hood) and Fiddler see the response travelling over the wire to the client
- SendRequestResponse eventually times out and throws an exception
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SoapClient.SendRequestResponse 知道传出请求 SOAP 标头中的 MessageID，并且在收到 RelatesTo 值与原始 MessageID 匹配的消息之前不会完成调用。因此，如果您正在制作响应程序/存根，则需要从请求中解析出 MessageID，并将其注入到响应的 SOAP 标头中的 RelatesTo 字段中。
有点奇怪的是，它不只是在任何有效的 SOAP 消息之后返回并由于不匹配而抛出期望。也许这是 SOAP Web 服务标准的一部分。我没有调查。
示例：
请求：
响应：
RelatesTo 值与请求中的 MessageID 值相同。响应中的 MessageID 是新的且唯一的，因为响应消息不是请求消息。
SoapClient.SendRequestResponse is aware of the MessageID in the outgoing request SOAP header and won't complete the call until it receives a message with a RelatesTo value that matches the original MessageID. So if you're crafting a responder/stub you much parse out the MessageID from the request and inject it into the RelatesTo field in the SOAP header of the response.
It's a little odd that it doesn't just return after any valid SOAP message and throw an expection because of the mismatch. Perhaps this is part of the SOAP web services standard. I didn't look into it.
Example:
Request:
Response:
The RelatesTo value is the same as the MessageID value in the request. The MessageID in the response is new and unique because the response message is not the request message.