在某些浏览器中首次未请求 clientaccesspolicy.xml
我在 Silverlight 4 中遇到了跨域 Web 服务调用的奇怪问题。
启动后，应用程序立即在下载的同一主机上调用 Web 服务，但在不同的端口上（例如，应用程序驻留在 < a href="http://www.mydomain.com:80" rel="noreferrer">http://www.mydomain.com:80 并且网络服务位于 http://www.mydomain.com:81）。不涉及 SSL。 主机提供了正确的 clientaccesspolicy.xml 文件，并且大部分时间一切正常（例如 99.9%）。
但在某些情况下，浏览器不会请求 clientaccesspolicy.xml，因此 Web 服务调用会被阻止并因跨域错误而失败。
在典型情况下，这是您使用 Fiddler 或 Chrome 开发人员工具看到的请求序列：
- index.html（托管 silverlight 应用程序的页面）
- silverlight.js
- application.xap
- clientaccesspolicy.xml（正确请求和下载）
- Web 服务调用
在某些情况下但是您只能看到
- index.html（托管 silverlight 应用程序的页面）
- silverlight.js
- application.xap
- ->跨域错误（未请求客户端访问策略，未调用 Web 服务）。
如果满足以下所有条件，这种情况只会发生在少数计算机（全部运行 Windows 7）上：
- 应用程序在 Chrome、Firefox 或浏览器外（IE 始终有效）中运行
- 第一次加载页面时（即，如果您点击浏览器的重新加载按钮，问题就会消失。关闭/重新启动浏览器，第一次仍然遇到问题）
- 没有 Fiddler 运行（如果你通过 Fiddler 运行流量，问题就来了消失）。不过 Chrome 开发者工具没有任何效果。
- 该计算机位于与应用程序服务器相同的域内。如果从外部网络（同一台机器）访问该页面，则不存在该问题。
在那些机器上，在那些情况下，问题是 100% 可重现的。
可能是什么原因造成的？我可以执行哪些步骤来跟踪问题？
I'm running into a weird issue with a crossdomain webservice call in Silverlight 4.
Immediately after starting, the application calls a webservice on the same host from where it has been downloaded but on a different port (for ex. the application resides at http://www.mydomain.com:80 and the webservice is at http://www.mydomain.com:81). No SSL involved.
The host provides a proper clientaccesspolicy.xml file and everything works correctly most of the time (like 99.9%).
In some cases however, the browser does not request clientaccesspolicy.xml and as a result the webservice call is blocked and fails with a cross-domain error.
In the typical case this is the sequence of requests you see with Fiddler or Chrome developer tools:
- index.html (the page hosting the silverlight app)
- silverlight.js
- application.xap
- clientaccesspolicy.xml (requested and downloaded correctly)
- webservice call
In some instances however you only see
- index.html (the page hosting the silverlight app)
- silverlight.js
- application.xap
- -> cross domain error (no clientaccesspolicy requested, no web service call).
This only happens on a minority of machines (all running Windows 7) if all these conditions are true:
- application running within Chrome, Firefox or out-of-the browser (IE always works)
- it's the first time you load the page (i.e. if you hit the browser's reload button the problem goes away. Close/restart browser and the first time you still have the problem)
- no Fiddler running (if you run traffic through Fiddler the problem goes away). Chrome developer tools have no effect though.
- the machine is inside the same domain as the application server. If you access the page from an external network (with the same machine), the problem is not there.
On those machines, under those circumstances, the problem is 100% reproducible.
What could be causing this? What steps can I perform to track the issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题显然相当罕见，但在微软的帮助下我找到了解决方案。我将其发布以供将来参考，希望这种情况不会再次发生。
作为一项安全措施，Silverlight 会阻止 Internet 区域和本地 Intranet 区域之间的任何跨域调用。在这种情况下，它甚至不会请求 clientaccesspolicy.xml。因此，如果应用程序托管在 www.myhost.com（Internet 区域）上，Silverlight 会阻止他调用 www.another.com（本地 Intranet 区域）上的 Web 服务。
这篇博文< /a> 详细解释一下。
因此，如果您出现以下一种或多种症状（尽管已经放弃了明显的跨域错误，例如格式错误或放错位置的 clientaccesspolicy.xml）：
为了将应用程序主机和 Web 服务放在同一安全区域中，可能值得尝试以下操作：
或者
This problem is obviously quite rare, but with some help from Microsoft I've found the solution. I'm posting it for future reference so that hopefully this won't happen again.
As a security measure, Silverlight blocks any cross-domain call between the Internet zone and the Local Intranet zone. In that case it does not even request clientaccesspolicy.xml. So if the application is hosted on www.myhost.com (Internet zone), Silverlight prevents him from calling a webservice on www.another.com (Local Intranet zone).
This blog post explains it in detail.
So if you have one or several of the following symptoms (despite having discarded the obvious crossdomain errors like a malformed or misplaced clientaccesspolicy.xml):
It may be worth to attempt the following, in order to put the application host and the web service in the same security zone:
OR