掙脫瀏覽器的束縛(6) - AJAX也跨域名
標(biāo)題有些唬人的成分,因為這里跨的只是子域名。
事情的經(jīng)過是這樣的,還是那個個人門戶網(wǎng)站。其中有個功能就是RSS訂閱,每個訂閱作為一個模塊出現(xiàn)在頁面上。如果一個用戶訂閱了比較多的RSS,則在
打開頁面時所有的RSS模塊就會開始加載,這時候可能就會需要十幾秒甚至更長的時間才能加載完畢。這時,如果用戶需要作別的AJAX操作——比如保存頁面
設(shè)置——那么長時間的等待就不可避免了,誰讓瀏覽器對于相同域名只能同時存在兩個連接呢?不過這可不是一個好的用戶體驗,那么我們需要怎么做呢?
第一種做法可能比較容易想到,我們可以自己編寫代碼維護(hù)一個Priority
Queue,為每個請求附加一個“優(yōu)先級”信息,這樣我們就可以把重要的請求率先發(fā)出。這樣就可以在一定程度上解決用戶的等待問題??上н@個方法還是無法
突破兩個連接的限制。于是第二種做法,我們就要設(shè)法突破兩個連接的限制了。如果能夠向別的域名發(fā)出AJAX請求,不也就能避免重要的請求被大量的請求所阻
塞了嗎?
我們還是從頭看起,一點(diǎn)一點(diǎn)地來解決這個問題。
阻塞的AJAX請求
我們先來證實(shí)一下請求的阻塞情況吧。我們使用如下的代碼:
連續(xù)發(fā)起三個請求 function simpleRequest() { var request = new XMLHttpRequest(); request.open ("POST ", "Script.ashx "); request.send(null ); }function threeRequests() { simpleRequest(); simpleRequest(); simpleRequest(); }
當(dāng)執(zhí)行threeRequests時就會連續(xù)發(fā)出3個相同域名的請求,還是通過統(tǒng)計圖表來查看阻塞的效果(如圖11):
每個請求需要花費(fèi)1.5秒的時間。很明顯,第三個請求必須等到第一個請求結(jié)束之后才能執(zhí)行,因此總共需要進(jìn)行3秒多鐘才能執(zhí)行完畢。我們要改變的就是這個狀況。
傳統(tǒng)的跨域名異步請求解決方案
AJAX安全性的唯一保證,似乎就是對于跨
域名(Cross-Domain)AJAX請求的限制。除非打開本地硬盤的網(wǎng)頁,或者在IE中將跨域名傳輸數(shù)據(jù)的限制打開,否則向其他域名發(fā)出AJAX請
求都會被禁止。而且對于跨域名的判斷非常嚴(yán)格,不同的子域名,或者相同域名的不同端口,都會被認(rèn)作是不同的域名,我們不能向它們的資源發(fā)出AJAX請求。
從表面上看起來似乎沒有辦法打破這個限制,還好我們有個救星,那就是iframe!
iframe雖然不在標(biāo)準(zhǔn)中出現(xiàn),但是由于
它實(shí)在有用,F(xiàn)ireFox也“不得不”對它進(jìn)行了支持(類似的還有innerHTML)。網(wǎng)上已經(jīng)有一些跨域名發(fā)出異步請求的做法,但是它們實(shí)在做的不
好。它們的簡單工作原理如下:在另一個域名下放置一個特定的頁面文件作為Proxy,主頁面將異步請求的信息通過Query
String傳遞入iframe里的Proxy頁面,Proxy頁面在AJAX請求執(zhí)行完畢后將結(jié)果放在自己location的hash中,而主頁面會對
iframe的src的hash值進(jìn)行輪詢,一旦發(fā)現(xiàn)它出現(xiàn)了改變,則通過hash值得到需要的信息。
這個方法的實(shí)現(xiàn)比較復(fù)雜,而且功能有限。在
IE和FireFox中,對于URL的長度大約可以支持2000個左右的字符。對于普通的需求它可能已經(jīng)足夠了,可惜如果真要傳遞大量的數(shù)據(jù),這就遠(yuǎn)遠(yuǎn)不
夠了。與我們一會兒要提出的解決方案相比,可能它唯一的優(yōu)勢就是能夠跨任意域名進(jìn)行異步請求,而我們的解決方案只能突破子域名的限制。
那么現(xiàn)在來看看我們的做法!
優(yōu)雅地突破子域名的限制
我們突破子域名限制的關(guān)鍵還是在于iframe。
iframe是的好東西,我們能夠跨過子域
名來訪問iframe里的頁面對象,例如window和DOM結(jié)構(gòu),包括調(diào)用JavaScript(通過window對象)——我們將內(nèi)外頁面的
document.domain設(shè)為相同就可以了。然后在不同子域名的頁面發(fā)起不同的請求,把結(jié)果通過JavaScript進(jìn)行傳遞即可。唯一需要的也僅
僅是一個簡單的靜態(tài)頁面作為Proxy而已。
我們現(xiàn)在就來開始編寫一個原形,雖然簡單,但是可以說明問題。
首先,我們先來編寫一個靜態(tài)頁面,作為放在iframe里的Proxy,如下:
SubDomainProxy.html < html xmlns ="http://www.w3.org/1999/xhtml" > < head > < title > Untitled Page</ title > < script type ="text/javascript" language ="javascript" > document .domain = "test.com "; function sendRequest(method, url) { var request = new XMLHttpRequest(); request.open (method, url); request.send(null ); } </ script > </ head > < body > </ body > </ html >
然后我們再編寫我們的主頁面:
[url]http://www.test.com/Default.html[/url] < html xmlns ="http://www.w3.org/1999/xhtml" > < head runat ="server" > < title > Untitled Page</ title > < script type ="text/javascript" language ="javascript" > document .domain = "test.com "; function simpleRequest() { var request = new XMLHttpRequest(); request.open ("POST ", "Script.ashx "); request.send(null ); } function crossSubDomainRequest() { var proxy = document .getElementById("iframeProxy ").contentWindow; proxy.sendRequest('POST', 'http: //sub0.test.com/Script.ashx '); } function threeRequests() { simpleRequest(); simpleRequest(); crossSubDomainRequest(); } </ script > </ head > < body > < input type ="button" value ="Request" onclick ="threeRequests()" /> < iframe src ="http://sub0.test.com/SubDomainProxy.html" style ="display:none;" id ="iframeProxy" > </ iframe > </ body > </ html >
當(dāng)執(zhí)行threeRequests方法時,將會同時請求[url]http://www.test.com[/url]以及[url]http://sub0.test.com[/url]兩個不同域名下的資源。很明顯,最后一個請求已經(jīng)不會受到前兩個請求的阻塞了(如圖12):
圖12:不同域名的請求不會被阻塞
令人滿意的結(jié)果!
雖說只能突破子域名,但是這已經(jīng)足夠了,不
是嗎?我們?yōu)槭裁匆獜?qiáng)求任意域名之間能夠異步通訊呢?更何況我們的解決方案是多么的優(yōu)雅!在下一篇文章中,我們將會為ASP.NET
AJAX客戶端實(shí)現(xiàn)一個完整的CrossSubDomainRequestExecutor,它會自動判斷是否正在發(fā)出跨子域名的請求,并選擇AJAX請
求的方式。這樣,客戶端的異步通訊層就會對開發(fā)人員完全透明。世上還會有比這更令人愉快的事情嗎?:)
注意事項
可能以下幾點(diǎn)值得一提:
我在出現(xiàn)這個想法之后也作了一些嘗試,最后發(fā)現(xiàn)創(chuàng)建XMLHttpRequest對象,調(diào)用open方法和send方法都必須在iframe中的頁面中執(zhí)行才能夠在IE和FireFox中成功發(fā)送AJAX請求。
在上面的例子中,我們向子域名請求的的路徑是[url]http://sub0.test.com/Script.ashx[/url]。請注意,完整的子域名不可以省略,否則在FireFox下就會出現(xiàn)權(quán)限不夠的錯誤,在調(diào)用open方法時就會拋出異?!坪鮂ireFox把它當(dāng)作了父頁面域名的資源了。
Windows
Live Contacts
Gadget使用了一種叫做Channel的技術(shù),用于解決跨任意域名傳遞數(shù)據(jù)的問題,我相當(dāng)佩服微軟技術(shù)人員的創(chuàng)造力。Channel技術(shù)是一種優(yōu)秀的
解決跨域名異步請求問題的解決方案,而且如果將它封裝成了組件,那么使用起來也會相當(dāng)優(yōu)雅(似乎微軟已經(jīng)準(zhǔn)備這么做了)。不過它和我們現(xiàn)在需要解決的問題
并不相同,如果有機(jī)會的話,我也會詳細(xì)的解釋一下Channel技術(shù)——但不是現(xiàn)在,因為我覺得我還沒有完全理解這個技術(shù)本身。