TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why JSONP is still mandatory

39 点作者 jlemoine大约 11 年前

6 条评论

homakov大约 11 年前
Not sure you made the right choice. This is how to use CORS without Preflights: <a href="http://homakov.blogspot.com/2014/01/how-to-use-cors-without-preflights.html" rel="nofollow">http:&#x2F;&#x2F;homakov.blogspot.com&#x2F;2014&#x2F;01&#x2F;how-to-use-cors-without-...</a><p>And this is why JSONP is almost always a bad idea (for sensitive data): <a href="http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jsonp-properly.html" rel="nofollow">http:&#x2F;&#x2F;homakov.blogspot.com&#x2F;2013&#x2F;02&#x2F;are-you-sure-you-use-jso...</a>
评论 #7744818 未加载
gkop大约 11 年前
Yes, you generally need a fallback when using CORS. When I can get away with it, I prefer running a proxy on my origin domain for this fallback, as it allows me to use all the headers I like (rather than JSONP).<p>The article doesn&#x27;t mention that many modern browsers don&#x27;t respect MaxAgeSec for caching the OPTIONS requests, at least not for more than a few minutes, which is another knock against CORS due to it causing 2x the number of requests versus JSONP.<p>Also the article doesn&#x27;t mention that, once you&#x27;ve already moved all your header data into the body, you can make simple requests that don&#x27;t require preflight OPTIONS requests [0] - which eliminates the problem with the 2x the requests.<p>[0] <a href="http://www.w3.org/TR/cors/#simple-cross-origin-request-0" rel="nofollow">http:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;cors&#x2F;#simple-cross-origin-request-0</a>
评论 #7744729 未加载
Arkadir大约 11 年前
At RunOrg, we&#x27;ve encountered this a few times with our CORS-only API.<p>It is against our philosophy to leave users behind only because they are locked in by outdated infrastructure. We still want to support them.<p>It is against our philosophy to bend the purity of our API to accommodate wrinkles in how outdated infrastructure declines to support standards. There will be no JSONP alternative to CORS in RunOrg.<p>The solution we propose each and every time is to mount a proxy to our API on the same domain as the site it is used on. Users on modern infrastructure reach us directly at api.runorg.com, users on CORS-hostile infrastructure reach us through the proxy and still get their data (albeit with decreased performance). It&#x27;s a fairly simple technical solution that leavers our API clean and supports non-CORS modes of access.
Udo大约 11 年前
A different position would be to simply let these misconfigured and badly written networking programs fail - and let them fail hard.<p>Yes, it will be painful in the short term and users will notice outages, but in the long run it will result in these issues being fixed. If we continue a policy of reversion to bad workarounds (which is really what JSONP is), we not only add complexity and the potential for obscure exploits to our own software, we ensure that nobody at Cisco et al will ever feel the pressure to fix these bugs.
评论 #7744779 未加载
评论 #7744705 未加载
puppetmaster3大约 11 年前
It is a bit like having to support IE6.<p>At some point you have to move forward to CORS, because others have.
lukebaker大约 11 年前
Would using HTTPS prevent the VPN and various proxies from messing with the traffic as described in the article?
评论 #7744748 未加载