权衡跨域Javascript选项 [英] Weighing Cross Domain Javascript Options
问题描述
我有一些Intranet脚本，我想跨域使用.我正在使用jQuery 1.7并试图权衡我的选择.我知道3种选择.
I've got some intranet scripting I am trying to go cross domain with. I'm using jQuery 1.7 and trying to weigh my options. There are 3 options I know of.
- JSONP
- 在网络服务器标题上设置Access-Control-Allow-Origin
- 编写代理页面
使用JSONP，我仅限于GET请求.我想发布一些大数据，但URL长度限制不可行.
With JSONP I am limited to GET requests. I have some large data that I would like to post and it isn't feasible with URL length limits.
在服务器上设置Access-Control-Allow-Origin有助于jQuery在执行之前进行的任何预检请求.但是我受制于浏览器的限制，例如Chrome和IE6.我在Chrome 15上，从本地主机转到其他任何域都立即抛出.我已经阅读了IE7 +的本机XmlHttpReq图表，并且我认为这将是一个很好的解决方案，因为我仅从Intranet转到Intranet，但我猜连最新的chrome都不行.
Setting Access-Control-Allow-Origin on the server helps for any preflight requests jQuery might do before executing. But I'm at the mercy of browser constraints such as Chrome and IE6. I'm on Chrome 15 and going from localhost to any other domain immediately throws up. I've read the IE7+ native XmlHttpReq charts and I thought this would be a good solution as I'm going from intranet to intranet only but I guess not for even the latest chrome.
编写代理页面会起作用，但是我认为这可能是过多的前期工作.我在.NET WCF Web服务之间跳来跳去，有足够的烦恼来包装SOAP请求和设置内容类型.
Writing a proxy page will work but I think it might be too much up front work. I'm bouncing in between .NET WCF web services and have enough to worry about with wrapping SOAP requests and setting content types.
那么您有什么想法?是否需要考虑在Chrome中进行这项工作?除了IE7，我什么都可以忽略.还是应该只使用页面代理方法?
So what are your thoughts? Are there considerations I am missing to have this work in Chrome? I can ignore anything less than IE7. Or should I just go with the page proxy method?
推荐答案
按照我使用它们的顺序:
In the order that I would use them:
代理
要绝对确保获得所需的内容，请使用代理.对于小规模的东西，您可以在.htaccess中执行一线式操作，将所有URL(假设您使用的是Apache)重写为外部主机.工作正常，但是调试可能会有点困难，因此您最好准备好在目标服务器上读取日志文件，因为如果发生错误(例如500或类似的错误)，则会收到代理错误(通常为502)，而不是浏览器.唯一的不利方面是，如果负载太大，它就需要一台像样的服务器，但是只需将Apache切换到Ngnix即可为您带来很大的提升，因此请不要害怕使用它.
To be absolutely sure that you get what you want, go with proxy. For small scale stuff you can literally do a one-liner in .htaccess on rewrite all URLs (provided you are using Apache) to the external host. Works just fine, debugging might be a bit difficult though, so you better be ready to read the log files on the target server, since in case of error (like 500 or similar) you get a proxy error (usually 502) instead in the browser. The only negative side is that it needs a decent server, if the load gets too big, but simply switching Apache to Ngnix will give you a great boost, so don't be afraid to use it.
访问控制允许来源
很棒，但不受支持< IE8，Opera(虽然可以运行)和其他一些较旧的浏览器.如果不需要某些浏览器支持，请执行此操作. 关于使用CORS的有趣文章
A great thing, but not supported < IE8, Opera (working on it though) and some other older browsers. If certain browser support is not needed, go for this. A fun article on using CORS
JSONP
如果您负担不起代理产生的额外服务器负载，则可以通过将请求分解成多个部分并分别发送来解决POST限制，但这比简单代理更麻烦.除此之外，效果还不错.
If you can't afford the extra server load generated by proxying, you can maybe work around the POST limit by breaking requests up into parts and send them separately, but much more of a hassle than simply proxying. Other than that, works pretty well.
这篇关于权衡跨域Javascript选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
