跨域脚本javascript请求
我正在开发一个 ASP.NET MVC 应用程序，该应用程序由一个托管所有 JavaScript、CSS 和图像的网站组成，然后是使用该网站上托管的资源的主 Web 应用程序。
假设资源 URL 为 resources.example.com，Web 应用程序 URL 为 webapp.example.com
JavaScript 文件 IE9.js (http://code.google.com/p/ie7-js/) 之一为了工作，向 CSS 文件 (resources.example.com/styles.css) 发出请求，但是由于同源策略，该请求会被阻止，因为该请求是发送到另一个域的（http://en.wikipedia.org/wiki/Same_origin_policy）。
我想我已经找到了解决这个问题的方法，使用 resources.example.com 站点的 Access-Control-Allow-Origin 标头。我对此的理解是，这将允许向 resources.example.com 网站发出的任何请求，只要它们位于该标头中即可。
为了尝试这个，我将标头添加到网站的 web.config 中，如下所示：
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*"/>
</customHeaders>
</httpProtocol>
我认为这将允许任何请求运行权限，但是当我单步执行 IE9.js 到发出请求的位置时，它仍然会捕获请求 CSS 文件 resources.example.com/styles.css 时出现 PermissionDenied 错误。
CSS 必须托管在其他域上，并且 IE9.js 需要能够请求它。我相信答案与这些 HTTP 标头有关，但我可能误解了如何使用它们。
对此问题的任何见解将不胜感激。顺便说一句，我应该补充一点，javascript 文件是从 google code 网站链接到的：
<!--[if lt IE 9]>
<script src="http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE9.js"></script>
<![endif]-->
在条件注释中，这只是 IE 中的一个问题。任何解决方案都必须在 IE7+ 中运行。
更新：
我已经使用 IE 的 XDomainRequest 对象成功向 CSS 发出了请求。我现在取回的内容已被压缩，因此我只需要对其进行解码，然后我就应该离开了。当我让它工作时，我会发布完整的更新和答案。
更新：
最后，XDomainRequest 对象似乎不支持修改 Accept-Encoding 标头，这意味着响应似乎总是以编码形式返回，而解码这会减慢页面加载速度并且不会感觉正确的。此外，IE7 似乎不支持 XDomainRequest 对象，而 IE7 是必需支持的浏览器。
我唯一能想到的另一件事是设置一个 IE9.js 可以调用的处理程序，该处理程序将位于同一域上并加载所需文件的内容。这也感觉不太好，但这是我目前能想到的唯一其他解决方案。欢迎任何其他建议。
I am working on an ASP.NET MVC application which consists of a website where all the JavaScript, CSS and images are hosted and then the main web app which uses the resources hosted on this website.
Lets say that the resource url is resources.example.com and the web app url is webapp.example.com
One of the JavaScript files IE9.js (http://code.google.com/p/ie7-js/) in order to work makes a request to the CSS file (resources.example.com/styles.css), this however gets blocked as the request is to another domain this is because of the same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy).
I thought I had found a way around this using the Access-Control-Allow-Origin header to the resources.example.com site. My understanding of this was that this would then allow any requests made to the resources.example.com website would be permitted provided they were in that header.
To try this out I added the header to the web.config of the website as follows:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*"/>
</customHeaders>
</httpProtocol>
Which I thought would allow any request the permission to run, but when I step through IE9.js to the point where the request is made it still catches a PermissionDenied error when requesting the CSS file resources.example.com/styles.css.
The CSS has to be hosted on the other domain and IE9.js needs to be able to request it. I believe that the answer is to do with these HTTP headers but that I might have misunderstood how to use them.
Any insight on this issue would be appreciated. As an aside I should add that the javascript file is linked to from the google code website:
<!--[if lt IE 9]>
<script src="http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE9.js"></script>
<![endif]-->
in a conditional comment and this is only an issue in IE. Any solution has to work in IE7+.
Update:
I have successfully made a request to the CSS using XDomainRequest object for IE. The content I am now getting back is gzipped so I just need to decode it and I should be away. I will post a full update and answer when I have it working.
Update:
Further to the last, the XDomainRequest object doesn't seem to support being able to modify the Accept-Encoding header which means that the response seems to always be returned encoded and decoding this will slow down the page load and doesn't feel right. Furthermore it appears that the XDomainRequest object is not supported in IE7 which is a required supported browser.
The only other thing I can think of is to set up a handler which IE9.js can call instead which will be on the same domain and load the contents of the required file. This also does not feel great but is the only other solution I can currently think of. Any other suggestions are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
解决此问题的另一种方法是在 IIS 前面放置一个反向代理（例如 Nginx）。
然后将位置 proxy_pass 添加到 webapp.domain.com 和 resources.domain.com。以这种方式，它默认为 webapp.domain.com，但如果您使用 webapp.domain.com/resources，它将转到 resources.domain.com。
通过这种方式，客户端只需要一个源，因此可以进行跨站点脚本编写。
这个技巧在本地测试时也非常方便。
只是一个想法...
A another way of solving this problem can be to put a reverse-proxy (such as Nginx) in front of IIS.
Then add location proxy_pass to both webapp.domain.com and resources.domain.com. In such a way that it defaults to webapp.domain.com, but if you uses webapp.domain.com/resources it goes of to resources.domain.com.
In this way the client only asks for one origin, hence on cross-site scripting.
This trick is also very handy when testing locally.
Just an idea...
为了解决这个问题，我修改了 IE9.js 文件，该文件发出调用主 MVC Web 应用程序中处理程序的请求。然后，该处理程序可以向 IE9.js 所需的资源发出请求，因此它不需要直接向资源站点本身发出请求。
在问题中概述的场景中，我无法找到问题的另一种解决方案。
In order to get around this issue I modified IE9.js file that was making the request to call a handler in the main MVC web app. This handler could then make the requests to the resources that IE9.js needed and thus it didn't need to make the request to the resources site directly itself.
In the scenario outlined in the question I was unable to find another solution to the problem.