权衡跨域 Javascript 选项
我有一些内联网脚本正在尝试跨域。我正在使用 jQuery 1.7 并尝试权衡我的选择。我知道有 3 个选项。
- JSONP
- 在 Web 服务器标头上设置 Access-Control-Allow-Origin
- 编写代理页面
使用 JSONP 我仅限于 GET 请求。我想发布一些大数据，但由于 URL 长度限制而无法实现。
在服务器上设置 Access-Control-Allow-Origin 有助于 jQuery 在执行之前可能执行的任何预检请求。但我受到 Chrome 和 IE6 等浏览器限制的摆布。我使用的是 Chrome 15，从本地主机转到任何其他域都会立即出现问题。我已经阅读了 IE7+ 本机 XmlHttpReq 图表，我认为这将是一个很好的解决方案，因为我只是从 Intranet 转到 Intranet，但我想即使是最新的 chrome 也不是这样。
编写代理页面会起作用，但我认为这可能需要太多的前期工作。我在 .NET WCF Web 服务之间切换，并且需要担心包装 SOAP 请求和设置内容类型。
那么你的想法是什么？在 Chrome 中进行这项工作我是否遗漏了一些注意事项？我可以忽略 IE7 以下的任何内容。或者我应该使用页面代理方法？
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
- Setting Access-Control-Allow-Origin on the webserver header
- Writing a proxy page
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.
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.
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
按照我使用它们的顺序：
PROXY
为了绝对确定您得到了您想要的东西，请使用代理。对于小规模的东西，您实际上可以在 .htaccess 中执行一行操作，将所有 URL（假设您使用的是 Apache）重写到外部主机。工作得很好，不过调试可能有点困难，所以你最好准备好读取目标服务器上的日志文件，因为如果出现错误（如 500 或类似错误），你会得到一个代理错误（通常是 502），而不是在浏览器。唯一的缺点是它需要一个像样的服务器，如果负载太大，但简单地将 Apache 切换到 Ngnix 会给你带来很大的提升，所以不要害怕使用它。
Access-Control-Allow-Origin
很棒，但不支持 IE8、Opera（不过正在开发）和其他一些较旧的浏览器。如果不需要某些浏览器支持，请选择此。 一篇关于使用 CORS 的有趣文章
JSONP
如果您无法承受代理生成的额外服务器负载，您可以通过将请求分解为多个部分并单独发送来解决 POST 限制，但更多的是比简单的代理麻烦。除此之外，效果很好。
In the order that I would use them:
PROXY
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.
Access-Control-Allow-Origin
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
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.
至少还有一个其他选项 - eaxyXDM。它是一个专门为完成跨域javascript通信而设计的框架。
There is at least one other option - eaxyXDM. It is a framework specifically designed to accomplish cross-domain javascript communication.