jQuery .ajax調用bit.ly在IE中返回結果，但不返回FF或Chrome

我正在嘗試使用帶.ajax調用的jQuery調用bit.ly URL縮短服務。jQuery .ajax調用bit.ly在IE中返回結果，但不返回FF或Chrome

更新我想知道這是否是一個跨域安全問題？我正在從mysite.com調用bit.ly

<html><head> 
<script type="text/javascript" src="http://www.twipler.com/settings/scripts/jquery.1.4.min.js"></script> 
<script type="text/javascript"> 
jQuery.fn.shorten = function(url) 
{ 
    var resultUrl = url; 

    $.ajax(
    { 
    url: "http://api.bit.ly/shorten?version=2.0.1&login=twipler&apiKey=R_4e618e42fadbb802cf95c6c2dbab3763&longUrl=" + url, 
    async: false, 
    dataType: 'json', 
    data: "", 
    type: "GET", 
    success: 
    function (json) { resultUrl = json.results[url].shortUrl; } 
    }); 

    return resultUrl; 
} ; 
</script></head><body> 
<a href="#" 
     onclick="alert($().shorten('http://amiconnectedtotheinternet.com'));"> 
     Shorten</a> </body> </html>

這個工作在IE8，但在Firefox（3.5.9）不工作，也沒有在Chrome中。在這兩種情況下，'json'都是null。

頁眉在IE8

GET http://api.bit.ly/shorten?ver..[SNIP]..dtotheinternet.com HTTP/1.1 
Accept: application/json, text/javascript, */* 
Accept-Language: en-US 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; 
     SLCC2; .NET CLR 2.0.50727; Media Center PC 6.0; InfoPath.2; 
    .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729) 
Host: api.bit.ly 
Connection: Keep-Alive

頁眉在Chrome

GET http://api.bit.ly/shorten?versio..[SNIP]..nectedtotheinternet.com HTTP/1.1 
Host: api.bit.ly 
Connection: keep-alive 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 
    (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5 
Origin: file:// 
Accept: application/json, text/javascript, */* 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-US,en;q=0.8 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

所以，唯一明顯的區別是Chrome正在發送「來源：文件：//」和我不知道如何停止這樣做。

來源

2010-04-08 Dead account

請注意，你應該**從來沒有**在現實世界中做到這一點。通過在瀏覽器中縮短時間，您可以將API密鑰暴露給整個世界。使用這些API密鑰，任何人都可以代表您縮短。您應該始終像處理密碼一樣對待API密鑰和OAuth令牌。您可以查看我們的[最佳實踐]（http://dev.bitly.com/best_practices.html）doc瞭解更多信息。 – SeanOC 2014-04-24 12:37:01

使用Fiddler來驗證請求的實際有效負載以及來自bit.ly服務的響應。將IE請求/響應與Chrome瀏覽器進行比較，以確定不同之處。

由於瀏覽器發出請求的方式不同，我的（瘋狂）猜測是該服務正在向Firefox發送請求時發送錯誤消息。特別是，你追加url參數的方式似乎對我有點懷疑，爲了以防萬一，我會對它進行url編碼。

更新：確實HTTP標頭已經揭示了這個問題。 :-)

Origin header是由用戶代理添加時，它想要建議網站的請求是跨源請求。最近這個標頭顯然是Chrome has added support。當然：

Origin標頭的細節是仍在定案。我們將更新谷歌瀏覽器中的實現爲該規範根據來自Mozilla和W3C 和IETF社區的反饋發展而演變。

可能會發現您目前無法做任何事情來阻止Chrome發送該標頭。順便說一句，似乎Origin標題是由Firefox 3.6首次引入的，我懷疑你是那些運行所有瀏覽器中最新最好的人的人之一。 :-)

btw，XMLHttpRequest確實有跨域限制。所以，我想知道jQuery.Ajax是不是在IE8上使用新的XDomainRequest而不是XMLHttpRequest。

但是，回到你的問題 - 在這一點上都指向唯一的解決辦法還應該提供讓Ajax調用到您的網站，並從服務器的bit.ly通話。不是最佳的，我知道......

來源

2010-04-08 16:12:17

感謝您的提示，我會稍後再嘗試。有趣的是，如果你只是將請求URL粘貼到IE/FF/Chrome中，你會得到一個有效的響應：（ – 2010-04-08 16:17:48

我會假設在所有瀏覽器中提交的地址（至少是IE）肯定會對參數進行正確的url編碼。但是，如果在Firefox和Chrome中實現XMLHttpRequest需要調用代碼來完成並按照他們看到的那樣傳遞URL，那麼我不會感到驚訝，根據URI RFC（3896或3986 - 我總是忘記確切的數字），查詢參數允許在路徑的中間，所以沒有100％的方法知道參數中的URL是否不是路徑的一部分，也不應該被編碼。 – 2010-04-08 16:32:29

我添加了URLEncode插件並對URL進行了編碼仍然沒有喜悅我可能會更快地從我的網站調用bit.ly，並從jQuery調用我的網站 – 2010-04-08 18:43:30

快速和懶惰的方式來得到這個工作是使用JSONP。

即

$.ajax(
{ 
    url: Request, 
    async: false, 
    dataType: 'jsonp', 
    data: "", 
    type: "GET", 
    success: 
    function (json) { console.log(json.data.url); } 
});

應該在一切工作。

來源

2010-07-14 12:54:23

jQuery .ajax調用bit.ly在IE中返回結果，但不返回FF或Chrome

回答

相關問題