專利名稱：用于處理超文本傳輸協(xié)議請(qǐng)求的方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及超文本傳輸協(xié)議(HTTP，Hypertext Transfer Protocol)會(huì)話技術(shù)，尤 其涉及用于處理HTTP請(qǐng)求的方法和系統(tǒng)。
背景技術(shù)：
HTTP超文本傳輸協(xié)議是一種單向協(xié)議。所謂單向協(xié)議是指，根據(jù)HTTP協(xié)議，服務(wù) 器不能主動(dòng)向客戶端發(fā)出連接請(qǐng)求，只能被動(dòng)地等待并答復(fù)客戶端發(fā)出的HTTP請(qǐng)求。由于 HTTP其本身并不支持在服務(wù)器保存客戶端的狀態(tài)信息，因此引入了一種狀態(tài)管理機(jī)制，即 會(huì)話機(jī)制，用以在服務(wù)器與客戶端之間保持會(huì)話狀態(tài)。會(huì)話機(jī)制的引入克服了 HTTP的一些限制，使得能夠在客戶端及服務(wù)器維護(hù)各 HTTP請(qǐng)求間的關(guān)系。根據(jù)會(huì)話機(jī)制，當(dāng)客戶端初次連接服務(wù)器時(shí)，在服務(wù)器建立HTTP會(huì)話 并保存與該會(huì)話相關(guān)的變量，同時(shí)產(chǎn)生一個(gè)HTTP會(huì)話標(biāo)識(shí)(session id)用來(lái)識(shí)別該會(huì)話 的變量。接著，服務(wù)器會(huì)在HTTP響應(yīng)中指示瀏覽器在客戶端生成與該HTTP會(huì)話標(biāo)識(shí)對(duì)應(yīng) 的“Cookie”。Cookie是服務(wù)器存儲(chǔ)在客戶端的一小段文本，在會(huì)話期間，每次通過(guò)瀏覽器 向服務(wù)器發(fā)出HTTP請(qǐng)求時(shí)，都會(huì)將Cookie中包含的會(huì)話標(biāo)識(shí)包括在HTTP請(qǐng)求中發(fā)送給服 務(wù)器，從而使服務(wù)器能夠識(shí)別該會(huì)話，并獲得與該會(huì)話相關(guān)的變量。然而，在現(xiàn)有技術(shù)中，通常存在這樣的情況，S卩，通常在一個(gè)HTTP會(huì)話中需要運(yùn)行 與同一應(yīng)用對(duì)應(yīng)的多個(gè)應(yīng)用實(shí)例。由于同一應(yīng)用多個(gè)應(yīng)用實(shí)例的域名都是相同的，在這種 情況下，應(yīng)用的服務(wù)器為請(qǐng)求訪問(wèn)不同的應(yīng)用實(shí)例的所有HTTP請(qǐng)求均生成相同的會(huì)話標(biāo) 識(shí)(sessionid)，也就是說(shuō)，該多個(gè)應(yīng)用實(shí)例共享了同一個(gè)HTTP會(huì)話。此時(shí)，就可能會(huì)出現(xiàn) 問(wèn)題，例如數(shù)據(jù)混淆、數(shù)據(jù)丟失、數(shù)據(jù)出錯(cuò)等，并且嚴(yán)重影響用戶體驗(yàn)。圖1示出了傳統(tǒng)的、可能會(huì)出現(xiàn)問(wèn)題的具有多個(gè)應(yīng)用實(shí)例的應(yīng)用環(huán)境的示例。如 圖1所示，在該示例中，有兩個(gè)服務(wù)器，一個(gè)是門(mén)戶服務(wù)器110，另一個(gè)是軟件即服務(wù)應(yīng)用 (SaaS, Software As a Service)服務(wù)器，諸如結(jié)算服務(wù)器120。用戶可以通過(guò)瀏覽器以自己的用戶名和密碼登陸門(mén)戶服務(wù)器110，隨后用戶進(jìn)入 頁(yè)面100。在頁(yè)面100中，包括有三個(gè)用戶接口組件，即內(nèi)嵌框架(IFrame)101、內(nèi)嵌框架 102和內(nèi)嵌框架103。IFramelOUIFrame 102和IFrame 103都對(duì)應(yīng)于相同的結(jié)算應(yīng)用，因 此它們的接入點(diǎn)(IP地址)相同。然而，與IFrame 101對(duì)應(yīng)的服務(wù)實(shí)例是“A”公司的主數(shù) 據(jù)，與IFrame 102對(duì)應(yīng)的服務(wù)實(shí)例是“B”公司的主數(shù)據(jù)，而與IFrame 103對(duì)應(yīng)的服務(wù)實(shí)例 是與“C”公司對(duì)應(yīng)的主數(shù)據(jù)。在圖1的左下方示出了這三個(gè)IFrame都打開(kāi)時(shí)的Cookie 104的示例。從該 示例可以看出，Cookie 104中存在兩個(gè)會(huì)話標(biāo)識(shí)，即SESSIONID 105和SESSIONID 106。 SESSIONID 105用于在與門(mén)戶服務(wù)器110通信時(shí)使用，同時(shí)在門(mén)戶服務(wù)器110中保存有與 SESSI0NID105對(duì)應(yīng)的變量信息111。SESSIONID 106用于在與結(jié)算服務(wù)器120通信時(shí)使用， 同時(shí)在結(jié)算服務(wù)器120中保存有與SESSIONID 106對(duì)應(yīng)的變量信息121。根據(jù)現(xiàn)有技術(shù)，盡管在這種情況下存在與結(jié)算應(yīng)用對(duì)應(yīng)的三個(gè)應(yīng)用實(shí)例，但在與結(jié)算服務(wù)器120通信時(shí)，卻都是使用SEESI0NID 106，這是因?yàn)閼?yīng)用服務(wù)器(結(jié)算服務(wù)器) 對(duì)于請(qǐng)求訪問(wèn)這三個(gè)應(yīng)用實(shí)例的HTTP請(qǐng)求只分配一個(gè)HTTP會(huì)話標(biāo)識(shí)(session id)—— SESSI0NID106。由于利用該SESSI0NID 106根本無(wú)法區(qū)分正在使用的是哪個(gè)應(yīng)用實(shí)例，因 此通常會(huì)出現(xiàn)問(wèn)題。這是因?yàn)樵趯?duì)“A”公司的主數(shù)據(jù)進(jìn)行操作之后，結(jié)算服務(wù)器120處所 存儲(chǔ)的會(huì)話變量是與“A”公司相關(guān)的值，而在對(duì)“B”公司的主數(shù)據(jù)進(jìn)行操作后，結(jié)算服務(wù)器 120處所存儲(chǔ)的會(huì)話變量可能是與“B”公司相關(guān)的值。因此，在操作了 “B”公司的主數(shù)據(jù) 后，再提交訪問(wèn)“A”公司的HTTP請(qǐng)求以返回查看“A”公司的主數(shù)據(jù)，此時(shí)看到的實(shí)際可能 是與“B”公司相關(guān)的主數(shù)據(jù)。這造成了極大的混亂，并且還會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)誤的問(wèn)題。為了解決該問(wèn)題，在一些應(yīng)用中，特別地設(shè)計(jì)了一種機(jī)制，該機(jī)制在檢測(cè)到在同一 HTTP會(huì)話期間要求實(shí)例化同一應(yīng)用的多個(gè)服務(wù)實(shí)例時(shí)，禁止該操作。換句話講，如果想要處 理其他公司的數(shù)據(jù)，必須結(jié)束當(dāng)前HTTP會(huì)話，重新連接服務(wù)器。利用這種方式，雖然避免了 數(shù)據(jù)混亂和數(shù)據(jù)錯(cuò)誤的問(wèn)題，但是卻非常麻煩，給用戶帶來(lái)了很不好的體驗(yàn)。因此，這種解 決方案在根本上是不能滿足商業(yè)需求的。還有另一種解決方案，即僅確保最后接入的服務(wù)實(shí)例的數(shù)據(jù)正確。這種方案簡(jiǎn)單， 但是用戶不能查看先前應(yīng)用實(shí)例的主數(shù)據(jù)。這依然給用戶帶來(lái)了很大的不便。雖然圖1示出了結(jié)算服務(wù)器和門(mén)戶服務(wù)器位于同一域中的環(huán)境，實(shí)際上在結(jié)算服 務(wù)器和門(mén)戶服務(wù)器處于不同域時(shí)也同樣會(huì)存在這些問(wèn)題。

發(fā)明內(nèi)容
為此，本發(fā)明提供了一種用于處理HTTP請(qǐng)求的方法和系統(tǒng)，以便克服現(xiàn)有技術(shù)中 的問(wèn)題。根據(jù)本發(fā)明的一個(gè)方面，提供了一種用于處理超文本傳輸協(xié)議HTTP請(qǐng)求的方法， 包括接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求；如果所述原始HTTP請(qǐng)求要訪問(wèn)的 域名與所述應(yīng)用的域名相同，將所述原始HTTP請(qǐng)求要訪問(wèn)的域名修改為與所述應(yīng)用的域 名不同的新域名，以生成要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求，并且將所述新的 HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)，其中所述原始HTTP請(qǐng) 求要訪問(wèn)的域名和所述新域名對(duì)應(yīng)于相同的IP地址。在本發(fā)明的一個(gè)實(shí)施方式中，所述用于處理超文本傳輸協(xié)議HTTP請(qǐng)求的方法還 包括如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名不同，直接將所述原始HTTP 請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)。根據(jù)本發(fā)明的另一方面，提供了一種用于處理超文本傳輸協(xié)議HTTP請(qǐng)求的系統(tǒng)， 包括接收模塊，用于接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求；修改模塊，被配置為 如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同，將所述原始HTTP請(qǐng)求要訪 問(wèn)的域名修改為與所述應(yīng)用的域名不同的新域名，以生成要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的 新的HTTP請(qǐng)求；以及發(fā)送模塊，被配置為將所述新的HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以 對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)，其中所述原始HTTP請(qǐng)求要訪問(wèn)的域名和所述新域名對(duì)應(yīng)于 相同的IP地址。在本發(fā)明的一個(gè)實(shí)施方式中，所述發(fā)送模塊還被配置為如果所述原始HTTP請(qǐng)求 要訪問(wèn)的域名與所述應(yīng)用的域名不同，直接將所述原始HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)。通過(guò)本發(fā)明的方法和系統(tǒng)，可以避免現(xiàn)有技術(shù)中在同一超文本傳輸協(xié)議會(huì)話中運(yùn) 行同一應(yīng)用的多個(gè)服務(wù)實(shí)例時(shí)出現(xiàn)的諸如數(shù)據(jù)混淆、數(shù)據(jù)錯(cuò)誤、使用不便等各種問(wèn)題，并給 用戶帶來(lái)了良好的體驗(yàn)，從而很好地滿足了商業(yè)需求。


通過(guò)對(duì)結(jié)合附圖所示出的實(shí)施方式進(jìn)行詳細(xì)說(shuō)明，本發(fā)明的上述以及其他特征將 更加明顯，本發(fā)明附圖中相同的標(biāo)號(hào)表示相同或相似的部件。在附圖中，圖1示出了傳統(tǒng)的、可能會(huì)出現(xiàn)問(wèn)題的具有多個(gè)應(yīng)用實(shí)例的應(yīng)用環(huán)境的示例；圖2示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理HTTP請(qǐng)求的方法的流 程圖；圖3示意性地示出了根據(jù)本發(fā)明另一實(shí)施方式的用于處理HTTP請(qǐng)求的方法的流 程圖；圖4A示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的對(duì)域名進(jìn)行判斷的方法的流程 圖；圖4B示意性地示出了根據(jù)本發(fā)明另一實(shí)施方式的對(duì)域名進(jìn)行判斷的方法的流程 圖；圖5示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理客戶端所提交的HTTP 請(qǐng)求的方法的流程圖；圖6示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的記錄與新域名相關(guān)信息的表；圖7示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理HTTP請(qǐng)求的系統(tǒng)的框 圖；圖8示意性地示出了根據(jù)本發(fā)明另一實(shí)施方式的用于處理HTTP請(qǐng)求的系統(tǒng)的框 圖；圖9示意性地示出了根據(jù)本發(fā)明另一實(shí)施方式的用于處理客戶端所提交的HTTP 請(qǐng)求的方法的流程圖。
具體實(shí)施例方式在下文中，將參考附圖通過(guò)實(shí)施方式對(duì)本發(fā)明提供的用于處理HTTP請(qǐng)求的方法 和系統(tǒng)進(jìn)行詳細(xì)地描述。圖2示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理HTTP請(qǐng)求的方法的流程圖。參 考圖2，首先在步驟201，接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求，這樣的HTTP請(qǐng)求 可以由使用該應(yīng)用的客戶從客戶端瀏覽器發(fā)出，之所以稱其為原始HTTP請(qǐng)求，是因?yàn)檫@樣 的HTTP請(qǐng)求直接由客戶端發(fā)出并在步驟201中被接收，中間沒(méi)有經(jīng)過(guò)修改處理。在步驟202中，如果所接收的原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名相同，則 將所接收到的原始HTTP請(qǐng)求的域名修改為新域名。從上文對(duì)圖1的描述中可以看出，對(duì) 于一個(gè)應(yīng)用而言，無(wú)論它具有多少實(shí)例，所有實(shí)例的域名都是相同的，也就是說(shuō)，客戶端無(wú) 論訪問(wèn)應(yīng)用的哪一個(gè)實(shí)例，所提交的HTTP請(qǐng)求中的域名部分都是應(yīng)用的域名。而在步驟 202中，所修改的新域名顯然是指不同于該應(yīng)用的域名的域名，而且這樣的新域名一定與該應(yīng)用的域名指向相同的IP地址，如果它們不指向相同的IP地址，則客戶端顯然無(wú)法正確 地訪問(wèn)其所要訪問(wèn)的應(yīng)用。因此，當(dāng)將原始HTTP請(qǐng)求要訪問(wèn)的域名修改為新域名后，該原 始HTTP請(qǐng)求也就成為了要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求。本領(lǐng)域技術(shù)人 員可以了解，兩個(gè)或者多個(gè)不同的域名指向相同的IP地址屬于“泛域名”技術(shù)。舉例而言， 比如用戶的域名是abc. com，那么將主機(jī)名設(shè)置為“*”，IP解析到比如218. 104.78. 100， 本領(lǐng)域技術(shù)人員應(yīng)當(dāng)了解“*”是通配符，它表明abc. com之前的所有子域名都將解析到 218. 104. 78. 100，這就意味著例如輸入 bbs. abc. com 或者 123. abc. com 或者 123. 234. abc. com 都將解析到 218. 104. 78. 100。根據(jù)本發(fā)明另一個(gè)實(shí)施方式，通過(guò)向接收到的原始HTTP請(qǐng)求的URL地址的頭部加 入隨機(jī)產(chǎn)生的符號(hào)來(lái)將原始HTTP請(qǐng)求要訪問(wèn)的域名修改為新的域名。例如，某應(yīng)用的URL 地址是HTTP: //oa. wds. com,現(xiàn)在客戶端請(qǐng)求訪問(wèn)該應(yīng)用對(duì)于公司A的實(shí)例a，在用戶通過(guò) 客戶端瀏覽器點(diǎn)擊公司A之后即向應(yīng)用的服務(wù)器發(fā)出原始HTTP請(qǐng)求HTTP://oa. wds. com/ oa ？ sid = a,這也就是該原始HTTP請(qǐng)求要訪問(wèn)的URL地址。其中該原始HTTP請(qǐng)求要訪 問(wèn)的域名是oa. wds. com( “/”之前的部分)，那么現(xiàn)在向該域名的頭部插入隨機(jī)產(chǎn)生的符 號(hào)“aabbcc”，使得經(jīng)修改后的新域名變成aabbcc. oa. wds. com。由上述“泛域名”的概念可 知，aabbcc. oa. wds. com和oa. wds. com 一定都將解析到相同的IP地址。應(yīng)當(dāng)了解，這只是 其中一種將原始HTTP請(qǐng)求要訪問(wèn)的域名修改為新域名的方式，本領(lǐng)域技術(shù)人員可以采取 多種其它方式修改原始HTTP請(qǐng)求要訪問(wèn)的域名，只要保證修改后的新的域名和原始HTTP 請(qǐng)求要訪問(wèn)的域名指向相同的IP地址，即可實(shí)現(xiàn)本發(fā)明的目的并落入本發(fā)明的保護(hù)范圍。根據(jù)本發(fā)明的又一個(gè)實(shí)施方式，上述隨機(jī)產(chǎn)生的符號(hào)應(yīng)當(dāng)受到一定的新域名模式 的限制。舉例而言，將新域名模式預(yù)先定義為“aa****”，也就是說(shuō)，向域名的頭部插入的符 號(hào)由6位組成，其中前兩位是固定的“aa”，而后4位才是隨機(jī)產(chǎn)生的其它符號(hào)。在預(yù)先定義 了這樣的新域名模式后，在修改原始HTTP請(qǐng)求要訪問(wèn)的域名時(shí)，就按照所定義的新域名模 式進(jìn)行修改。這樣做的其中一個(gè)目的是，可以將接收到的原始HTTP請(qǐng)求的域名的模式與預(yù) 先定義的新域名模式進(jìn)行比對(duì)，從而判斷原始HTTP請(qǐng)求要訪問(wèn)的域名是否與應(yīng)用的域名 相同。關(guān)于這部分內(nèi)容，在對(duì)附圖4B的文字描述中有詳細(xì)記載。還需要指出的是，在一個(gè)應(yīng)用包含多個(gè)應(yīng)用實(shí)例的情形下，為了對(duì)每個(gè)應(yīng)用實(shí)例 的HTTP會(huì)話進(jìn)行隔離，需要對(duì)訪問(wèn)每個(gè)應(yīng)用實(shí)例的HTTP請(qǐng)求分配不同的HTTP會(huì)話標(biāo)識(shí) (session id)，也就是說(shuō)，需要將訪問(wèn)每個(gè)應(yīng)用實(shí)例的HTTP請(qǐng)求(初次訪問(wèn)該應(yīng)用實(shí)例 時(shí))修改為不同的新的HTTP請(qǐng)求，只有這樣，才能保證應(yīng)用的服務(wù)器為訪問(wèn)每個(gè)應(yīng)用實(shí)例 的HTTP請(qǐng)求分配不同的HTTP會(huì)話標(biāo)識(shí)。在步驟203中，將包含新域名的要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求發(fā) 送至應(yīng)用的服務(wù)器，以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)了解，由于應(yīng)用的 服務(wù)器分配HTTP session (會(huì)話)是根據(jù)所接收到的HTTP請(qǐng)求中的域名部分來(lái)進(jìn)行的，也 就是說(shuō)對(duì)于具有相同的域名部分的HTTP請(qǐng)求分配相同的HTTP會(huì)話標(biāo)識(shí)(session id)，而 對(duì)于具有不同的域名部分的HTTP請(qǐng)求分配不同的HTTP會(huì)話標(biāo)識(shí)(session id)，因此經(jīng)步 驟202修改后的包含新域名的HTTP請(qǐng)求自然而然地就可以由應(yīng)用的服務(wù)器分配不同于原 始HTTP請(qǐng)求的HTTP會(huì)話標(biāo)識(shí)，從而如果對(duì)每一個(gè)針對(duì)同一應(yīng)用的不同應(yīng)用實(shí)例所提交的 原始HTTP請(qǐng)求都進(jìn)行這樣的修改，就可以使得雖然這些原始HTTP請(qǐng)求要訪問(wèn)的域名部分都相同，但是每一個(gè)原始HTTP請(qǐng)求最終都可以由應(yīng)用的服務(wù)器分配不同的HTTP會(huì)話標(biāo)識(shí)， 從而對(duì)HTTP會(huì)話進(jìn)行隔離。圖3根據(jù)本發(fā)明另一實(shí)施方式的用于處理HTTP請(qǐng)求的方法的流程圖?？梢岳斫?， 圖3是在圖2的基礎(chǔ)上包含了判斷步驟以及與客戶端交互步驟的流程圖。具體地，步驟301 與步驟201相同，接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求。在步驟302中，對(duì)接收到的原始HTTP請(qǐng)求進(jìn)行判斷，判斷該請(qǐng)求的域名部分是否 與應(yīng)用的域名相同。如果判斷結(jié)果為是，則執(zhí)行步驟303，如果判斷結(jié)果為否，則執(zhí)行步驟 307。在步驟303中，執(zhí)行與步驟202中相同的操作，將原始HTTP請(qǐng)求的域名修改為新 域名。在步驟304中，將包含修改后的新域名的新HTTP請(qǐng)求返回至客戶端，使得客戶端能 夠記錄對(duì)應(yīng)于應(yīng)用的特定實(shí)例的新域名。可選地，客戶端可以重新提交所述包含了修改后 的新域名的新的HTTP請(qǐng)求?？蛇x地，客戶端僅僅記錄對(duì)應(yīng)于應(yīng)用的特定實(shí)例的新域名，但 是并不重新提交所述包含了修改后的新域名的新的HTTP請(qǐng)求。需要指出的是，這里利用了 URL地址重定向技術(shù)(URLRedirection)，客戶端會(huì)自動(dòng)提交所述新的HTTP請(qǐng)求，也就是包 含被重定向后的URL地址的HTTP請(qǐng)求，而無(wú)需用戶在客戶端再次執(zhí)行提交HTTP請(qǐng)求的操 作。在這里，將新HTTP請(qǐng)求返回至客戶端而不是直接發(fā)送至應(yīng)用的目的在于，使得客戶端 知曉并記錄其所提交的原始HTTP請(qǐng)求被修改為什么樣的新的HTTP請(qǐng)求，這樣用戶在下一 次請(qǐng)求訪問(wèn)同一應(yīng)用實(shí)例時(shí)就可以直接提交被記錄下的包含新域名的新HTTP請(qǐng)求，從而 不用再次經(jīng)歷修改域名的過(guò)程，也就是在步驟302中判斷為否，然后直接執(zhí)行步驟307將原 始HTTP請(qǐng)求發(fā)送至所述應(yīng)用。需要指出的是，將新的HTTP請(qǐng)求返回至客戶端并非本發(fā)明 必須的步驟，本領(lǐng)域技術(shù)人員也可以選擇直接將新的HTTP請(qǐng)求發(fā)送至應(yīng)用，并且在下一次 客戶端提交訪問(wèn)同一實(shí)例的HTTP請(qǐng)求時(shí)重新對(duì)原始HTTP請(qǐng)求的域名進(jìn)行修改。在步驟305中接收由客戶端記錄完成后并且重新提交的新的HTTP請(qǐng)求，在步驟 306中將新的HTTP請(qǐng)求發(fā)送至應(yīng)用。需要指出的是，步驟305僅是本發(fā)明的一種實(shí)施方式， 可選地，客戶端僅僅記錄對(duì)應(yīng)于應(yīng)用的特定實(shí)例的新域名，但是并不重新提交所述包含了 修改后的新域名的新的HTTP請(qǐng)求。圖4A和圖4B針對(duì)圖3中的步驟302，進(jìn)一步給出了兩種根據(jù)本發(fā)明判斷原始HTTP 請(qǐng)求的域名是否與應(yīng)用的域名相同的實(shí)施例。如圖4a所示，在步驟401A中，獲取HTTP請(qǐng) 求要訪問(wèn)的URL地址。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)了解，在一個(gè)完整的HTTP請(qǐng)求中，除了該HTTP 請(qǐng)求要訪問(wèn)的URL地址外，還包括其它的一些信息例如cookie信息。而在步驟401A中僅 需要獲取HTTP請(qǐng)求要訪問(wèn)的URL地址，從而在步驟402中分析所獲取的URL地址的域名部 分。在步驟403A中，判斷所獲取的URL地址的域名部分是否與應(yīng)用域名列表中的域名 相同，如果是，則在步驟404A中確定原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名相同；如果 否，則在步驟405A中確定原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名不同。需要指出的是， 應(yīng)用域名列表是指已經(jīng)存在的記錄下所有應(yīng)用的域名的表格，這種判斷方法在所提供的應(yīng) 用的數(shù)量有限且較為固定的情形下具有優(yōu)勢(shì)，只要將HTTP請(qǐng)求的URL地址的域名部分通過(guò) 查表與應(yīng)用域名列表中列舉的域名一一比對(duì)，即可確定原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng) 用的域名是否相同。
下面參考圖4B所示的根據(jù)本發(fā)明另一判斷原始HTTP請(qǐng)求的域名與應(yīng)用的域名是 否相同的實(shí)施例。步驟401B和402B對(duì)應(yīng)于401A和402A，分別是獲取HTTP請(qǐng)求的URL地 址和分析所獲取的URL地址的域名部分，在此不再詳述。與圖4a所示的實(shí)施方式不同的是， 在步驟403B中，判斷所獲取的URL中的域名部分的模式與預(yù)定義的新域名模式是否相同。 如果是，則在步驟404B中確定原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名不同；如果否，則 在步驟405B中確定原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名相同。本領(lǐng)域技術(shù)人員應(yīng) 當(dāng)了解，當(dāng)所提供的應(yīng)用的數(shù)量較多或者動(dòng)態(tài)變化的情形下，圖4B所示的判斷方法具有優(yōu) 勢(shì)。這是因?yàn)?，如果?yīng)用的數(shù)量較多或者動(dòng)態(tài)變化，將難以實(shí)時(shí)地把所有應(yīng)用的域名一一預(yù) 先記錄，而通過(guò)比較原始HTTP請(qǐng)求的URL的域名部分的模式與預(yù)定義的新域名的模式，可 以判斷出原始HTTP請(qǐng)求要訪問(wèn)的域名是否與應(yīng)用的域名相同。新域名模式的具體示例在 圖2的文字描述中已有記載，在此不作過(guò)多描述。圖5示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理客戶端所提交的HTTP請(qǐng)求的方 法的流程圖。其中，步驟501至步驟504已經(jīng)在上文對(duì)圖2至圖4的描述中有過(guò)詳細(xì)記載， 這里重點(diǎn)描述客戶端與服務(wù)器建立通信后HTTP會(huì)話被隔離的過(guò)程。在步驟505中，應(yīng)用的服務(wù)器為新的HTTP請(qǐng)求生成HTTP會(huì)話標(biāo)識(shí)(session id)， 并將會(huì)話標(biāo)識(shí)返回至發(fā)出所述原始HTTP請(qǐng)求的客戶端。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)了解，此步驟 是由HTTP協(xié)議規(guī)范決定的，對(duì)于任何HTTP請(qǐng)求，根據(jù)會(huì)話機(jī)制，當(dāng)客戶端初次連接服務(wù)器 時(shí)，在服務(wù)器建立HTTP會(huì)話并保存與該會(huì)話相關(guān)的變量，同時(shí)產(chǎn)生一個(gè)HTTP會(huì)話標(biāo)識(shí)(ID) 用來(lái)識(shí)別該會(huì)話的變量。在步驟506，一旦應(yīng)用的服務(wù)器將HTTP會(huì)話標(biāo)識(shí)發(fā)送至客戶端，客戶端就記錄所 述會(huì)話標(biāo)識(shí)和修改后的域名的對(duì)應(yīng)關(guān)系。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)了解，根據(jù)HTTP協(xié)議規(guī)范， 客戶端可以自動(dòng)在本地cookie中記錄會(huì)話標(biāo)識(shí)和域名的對(duì)應(yīng)關(guān)系。在步驟507中，如果客 戶再次訪問(wèn)同一應(yīng)用實(shí)例，那么客戶端所提交的HTTP請(qǐng)求中就自動(dòng)包含了之前已經(jīng)修改 過(guò)并記錄下來(lái)的對(duì)應(yīng)于該應(yīng)用實(shí)例的新HTTP請(qǐng)求(參見(jiàn)步驟507)，并且包含了與新HTTP 請(qǐng)求要訪問(wèn)的域名所對(duì)應(yīng)的HTTP會(huì)話標(biāo)識(shí)(session id)(參見(jiàn)步驟508)。那么在步驟509 中，客戶端將HTTP會(huì)話標(biāo)識(shí)和HTTP請(qǐng)求一起發(fā)送至應(yīng)用(參見(jiàn)圖3的步驟302和307，當(dāng)檢 測(cè)到這樣的原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名不同時(shí)，直接將原始HTTP請(qǐng)求發(fā)送 至所述應(yīng)用)，從而利用所述會(huì)話標(biāo)識(shí)與應(yīng)用建立通信。由于對(duì)于不同的應(yīng)用實(shí)例，修改且 記錄的新的域名是不同的，因此由應(yīng)用的服務(wù)器分配的會(huì)話標(biāo)識(shí)也是不同的，這樣客戶端 請(qǐng)求訪問(wèn)同一應(yīng)用的不同應(yīng)用實(shí)例時(shí)就可以利用不同的會(huì)話標(biāo)識(shí)與應(yīng)用建立HTTP通信。需要指出的是，盡管圖5所示的流程圖中示出了應(yīng)用服務(wù)器生成HTTP會(huì)話標(biāo)識(shí)并 將會(huì)話標(biāo)識(shí)發(fā)送至客戶端、客戶端記錄會(huì)話標(biāo)識(shí)與域名的對(duì)應(yīng)關(guān)系、客戶端再次訪問(wèn)同一 實(shí)例時(shí)向應(yīng)用發(fā)送之前生成的會(huì)話標(biāo)識(shí)以及之前記錄的新域名等步驟(參見(jiàn)步驟505至 509)，并不意味著上述步驟是本發(fā)明的必要步驟。本領(lǐng)域技術(shù)人員可以了解，本發(fā)明的多個(gè) 實(shí)施方式正是利用現(xiàn)有技術(shù)中的HTTP協(xié)議規(guī)范(包括生成HTTP會(huì)話標(biāo)識(shí)以及在cookie 中記錄會(huì)話標(biāo)識(shí)，并且再次訪問(wèn)時(shí)自動(dòng)發(fā)送所述會(huì)話標(biāo)識(shí))的內(nèi)容，通過(guò)在訪問(wèn)某應(yīng)用實(shí) 例的原始HTTP請(qǐng)求要訪問(wèn)的域名與應(yīng)用的域名相同的情況下修改原始HTTP請(qǐng)求的域名， 來(lái)獲得不同的HTTP會(huì)話標(biāo)識(shí)，從而實(shí)現(xiàn)隔離HTTP會(huì)話的目的。也就是說(shuō)，上述步驟505至 509是由現(xiàn)有技術(shù)中的HTTP協(xié)議規(guī)范決定的，必須建立在步驟503修改域名的基礎(chǔ)上才能實(shí)現(xiàn)隔離HTTP會(huì)話的目的，記載步驟505至509的目的是為了詳細(xì)描述隔離HTTP會(huì)話的 全過(guò)程，它們并不構(gòu)成本發(fā)明的實(shí)施方式所提供的技術(shù)方案中的技術(shù)特征的一部分。圖6示意性地示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的記錄與新域名相關(guān)信息的表。根 據(jù)上文的描述，客戶端初次訪問(wèn)某應(yīng)用實(shí)例時(shí)的HTTP請(qǐng)求中的域名部分會(huì)被修改為新的 域名，從而生成新的HTTP請(qǐng)求，而客戶端以后再次訪問(wèn)同一應(yīng)用實(shí)例時(shí)就可以利用已經(jīng)生 成并記錄下來(lái)的新域名發(fā)出fflTP請(qǐng)求，并且利用已經(jīng)由應(yīng)用的服務(wù)器生成的對(duì)應(yīng)于新的 HTTP請(qǐng)求的會(huì)話標(biāo)識(shí)與應(yīng)用服務(wù)器建立通信。那么根據(jù)本發(fā)明的一實(shí)施例，可以限定并記 錄新域名的有效期限，并且記錄訪問(wèn)某實(shí)例的最后訪問(wèn)時(shí)間。也就是說(shuō)，限定之前已經(jīng)被記 錄下來(lái)的新域名僅在一定時(shí)間期限內(nèi)有效，超過(guò)這一期限后，即使客戶端再次訪問(wèn)同一應(yīng) 用實(shí)例，也不能利用已有的新域名和已經(jīng)的HTTP會(huì)話標(biāo)識(shí)與應(yīng)用服務(wù)器建立通信，而是需 要重新發(fā)出包含與應(yīng)用的域名相同的域名部分的原始HTTP請(qǐng)求，并再次對(duì)其進(jìn)行修改以 生成新的HTTP請(qǐng)求。此實(shí)施方式對(duì)于提高網(wǎng)絡(luò)應(yīng)用訪問(wèn)系統(tǒng)的安全性是有幫助的。具體 地，參考圖6示出的表，某應(yīng)用具有兩個(gè)應(yīng)用實(shí)例，分別是公司A的實(shí)例和公司B的實(shí)例，最 后訪問(wèn)公司A實(shí)例的時(shí)間是2008年1月23日16:05分，對(duì)應(yīng)于公司A的新域名的時(shí)間期 限是15分鐘；最后訪問(wèn)公司B實(shí)例的時(shí)間是2008年1月23日16:08分，對(duì)應(yīng)于公司B的 新域名的時(shí)間期限是23分鐘。假設(shè)當(dāng)前時(shí)間是2008年1月23日16 30分，客戶端再次提 交訪問(wèn)公司A實(shí)例的請(qǐng)求，那么檢測(cè)到已超出15分鐘的新域名有效期限，于是提交包含域 名oa.wds.com的HTTP請(qǐng)求，并對(duì)其進(jìn)行修改。假設(shè)同樣在2008年1月23日16:30分，客 戶端再次提交訪問(wèn)公司B實(shí)例的請(qǐng)求，那么檢測(cè)到尚未超出23分鐘的新域名有效期限，于 是提交包含域名XEQIES23. oa. wds. com的HTTP請(qǐng)求，無(wú)需對(duì)其進(jìn)行修改，直接發(fā)送至應(yīng)用 的服務(wù)器。圖7示出了根據(jù)本發(fā)明一個(gè)實(shí)施方式的用于處理HTTP請(qǐng)求的系統(tǒng)的框圖。該系 統(tǒng)在圖7中總體上由700表示。具體地，系統(tǒng)700包括接收模塊701，域名修改模塊702和 發(fā)送模塊703。接收模塊701用于接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求。域名修 改模塊702用于在所述原始HTTP請(qǐng)求的域名與應(yīng)用的域名相同的情況下，將原始HTTP請(qǐng) 求的域名修改為新域名，以生成要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求。其中利用 泛域名技術(shù)使得新域名與原始HTTP請(qǐng)求的域名指向相同的IP地址——應(yīng)用的IP地址，只 有這樣才能保證客戶端對(duì)應(yīng)用的正確訪問(wèn)。發(fā)送模塊703用于將包含新域名的新的HTTP 請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)。圖7所示的系統(tǒng)包含的模塊 701-703可以理解為分別對(duì)應(yīng)于圖2所示的方法的步驟201-203，具體的修改域名的實(shí)施方 式、以及對(duì)修改后的新域名的模式限制等內(nèi)容可參考圖2的文字描述部分的詳細(xì)記載。圖8示出了根據(jù)本發(fā)明另一實(shí)施方式的用于處理HTTP請(qǐng)求的系統(tǒng)的框圖。圖8所 示的系統(tǒng)在總體上由800表示。具體地，系統(tǒng)800包括接收模塊801，域名判斷模塊802，域 名修改模塊803，返回模塊804，發(fā)送模塊805和記錄模塊806。接收模塊801、域名修改模 塊803和發(fā)送模塊805分別對(duì)應(yīng)于圖7所示的系統(tǒng)中的模塊701-703，也對(duì)應(yīng)于圖2所示的 方法中的步驟201-203?？梢岳斫庥蛎袛嗄K802對(duì)應(yīng)于圖3所示的步驟302，該模塊用 于判斷由接收模塊801接收到的訪問(wèn)應(yīng)用實(shí)例的原始HTTP請(qǐng)求要訪問(wèn)的域名是否與應(yīng)用 的域名相同。在域名判斷模塊輸出判斷結(jié)果為是情況下，由域名修改模塊803對(duì)域名進(jìn)行 修改，并由返回模塊804將修改后的新域名返回至客戶端。域名判斷模塊802可以利用圖4a和圖4b所示的實(shí)施方式進(jìn)行判斷，具體判斷的方法已在圖4的文字描述部分詳細(xì)記載。 需要指出的是，在此實(shí)施方式中，接收模塊801除了接收原始HTTP請(qǐng)求外，也要接收客戶端 重新提交的新的HTTP請(qǐng)求。發(fā)送模塊805用于將新的HTTP請(qǐng)求發(fā)送至應(yīng)用，還用于在域 名判斷模塊802的輸出為“否”的情況下，直接將原始HTTP請(qǐng)求發(fā)送至應(yīng)用。記錄模塊806 用于記錄對(duì)應(yīng)用實(shí)例訪問(wèn)的最后時(shí)間以及對(duì)應(yīng)于該應(yīng)用實(shí)例的新域名的有效期限等信息， 具體內(nèi)容可以參照?qǐng)D6所示的記錄表。圖9示出了根據(jù)本發(fā)明另一實(shí)施方式的用于處理客戶端所提交的HTTP請(qǐng)求的方 法的流程圖。根據(jù)本發(fā)明一實(shí)施方式的用于處理HTTP請(qǐng)求的系統(tǒng)可以部署于應(yīng)用服務(wù)器 側(cè)。該系統(tǒng)用于實(shí)現(xiàn)圖2至圖5所示的方法。本領(lǐng)域技術(shù)人員可以了解，該系統(tǒng)也可以部 署于應(yīng)用服務(wù)器之外，只要該系統(tǒng)可以在HTTP請(qǐng)求到達(dá)應(yīng)用服務(wù)器之前接收該HTTP請(qǐng)求 并對(duì)其進(jìn)行處理即可。如圖9所示，用戶(例如一家會(huì)計(jì)師事務(wù)所)登錄應(yīng)用門(mén)戶網(wǎng)站mm. wds. com,該 門(mén)戶網(wǎng)站可以提供多個(gè)應(yīng)用服務(wù)，例如包括會(huì)計(jì)服務(wù)、人力資源管理服務(wù)、IT服務(wù)等等。這 些應(yīng)用服務(wù)可以是軟件即服務(wù)SaaS。然后用戶點(diǎn)擊該應(yīng)用門(mén)戶網(wǎng)站上提供的多種應(yīng)用之 一例如會(huì)計(jì)服務(wù)，該會(huì)計(jì)服務(wù)的域名是oa. wds. com，用戶進(jìn)入會(huì)計(jì)服務(wù)的主頁(yè)后，通過(guò)客戶 端瀏覽器點(diǎn)擊公司A的應(yīng)用實(shí)例來(lái)對(duì)公司A提供會(huì)計(jì)服務(wù)。用戶點(diǎn)擊了頁(yè)面上的“公司A” 之后，發(fā)出一個(gè)HTTP請(qǐng)求，該HTTP請(qǐng)求要訪問(wèn)的URL地址是HTTP://oa. wds. com/oa ？ sid 三互，用于隔離HTTP會(huì)話的系統(tǒng)接收到這個(gè)HTTP請(qǐng)求，分析出該HTTP請(qǐng)求要訪問(wèn)的域名是 oa. wds. com(域名是指URL地址中HTTP://之后并且“/”之前的部分)，并且判斷出該域名 與會(huì)計(jì)服務(wù)的應(yīng)用的域名相同，于是將該域名修改為SZQIES12. oa. wds. com，并將包含了修 改后的域名的新HTTP請(qǐng)求返回至客戶端瀏覽器，客戶端自動(dòng)在本地記錄該修改后的域名， 然后重新發(fā)送新的HTTP請(qǐng)求。用于隔離HTTP會(huì)話的系統(tǒng)接收到這個(gè)新的HTTP請(qǐng)求后，判 斷出該HTTP請(qǐng)求的域名部分不是應(yīng)用的域名，于是向應(yīng)用的服務(wù)器發(fā)送該HTTP請(qǐng)求。需要 指出的是，用于隔離HTTP會(huì)話的系統(tǒng)還可以既將包含了修改后的域名的新HTTP請(qǐng)求返回 至客戶端瀏覽器，又將包含了修改后的域名的新HTTP請(qǐng)求發(fā)送至應(yīng)用的服務(wù)器，而不需要 由客戶端重新發(fā)送新的HTTP請(qǐng)求。之后，根據(jù)HTTP協(xié)議規(guī)范，應(yīng)用服務(wù)器響應(yīng)該新的HTTP 請(qǐng)求，并為域名SZQIES12. oa. wds. com生成對(duì)應(yīng)的HTTP會(huì)話標(biāo)識(shí)(session id) CDWDUWE,并 將該會(huì)話標(biāo)識(shí)隨著HTTP響應(yīng)發(fā)送至客戶端，由客戶端瀏覽器記錄在“公司A”實(shí)例的cookie 中。同樣地，從圖9可以看出，當(dāng)用戶在會(huì)計(jì)服務(wù)應(yīng)用主頁(yè)中點(diǎn)擊標(biāo)簽“公司B”后，應(yīng) 用服務(wù)器為修改后的域名XEQIES23. oa. wds. com生成對(duì)應(yīng)的HTTP會(huì)話標(biāo)識(shí)(session id) CDWDUST,并將該會(huì)話標(biāo)識(shí)隨著HTTP響應(yīng)發(fā)送至客戶端，由客戶端瀏覽器記錄在“公司B”實(shí) 例的cookie中。接下來(lái)，當(dāng)用戶再次點(diǎn)擊“公司A”標(biāo)簽時(shí)，由于客戶端已經(jīng)記錄了修改后的新域名 SZQIES12. oa. wds. com,因此自動(dòng)以新域名發(fā)送HTTP請(qǐng)求，并且發(fā)送之前在客戶端cookie 中記錄下來(lái)的對(duì)應(yīng)的HTTP會(huì)話標(biāo)識(shí)(session id) CDWDUWE。根據(jù)本發(fā)明一實(shí)施方式的系統(tǒng) 判斷出該HTTP請(qǐng)求的域名部分不是應(yīng)用的域名oa. wds. com,于是直接將該HTTP請(qǐng)求發(fā)送 至?xí)?jì)服務(wù)應(yīng)用，會(huì)計(jì)服務(wù)應(yīng)用服務(wù)器利用接收到的會(huì)話標(biāo)識(shí)CDWDUWE對(duì)該HTTP請(qǐng)求進(jìn)行 響應(yīng)。
同樣地，雖然圖9中沒(méi)有示出，本領(lǐng)域技術(shù)人員也可以了解，當(dāng)用戶再次點(diǎn)擊“公 司B”標(biāo)簽時(shí)，執(zhí)行上述類似的操作。此外，雖然在上面示出的實(shí)施方式中，結(jié)合SaaS應(yīng)用來(lái)描述本發(fā)明，但這只是示 例性的，本發(fā)明并非僅限于此。本發(fā)明中的應(yīng)用可以是任何適當(dāng)?shù)膽?yīng)用，諸如像電子郵件應(yīng) 用、網(wǎng)上銀行應(yīng)用等一般的網(wǎng)絡(luò)應(yīng)用。另外，雖然在上面示出的實(shí)施方式中，描述了本發(fā)明在一個(gè)瀏覽器實(shí)例的情況下 的應(yīng)用，但并不應(yīng)當(dāng)將其理解為是對(duì)本發(fā)明的限制。實(shí)際上，本發(fā)明適應(yīng)用于在一個(gè)HTTP 會(huì)話中需要運(yùn)行同一應(yīng)用的多個(gè)服務(wù)實(shí)例的環(huán)境，而與并非只是單個(gè)瀏覽器實(shí)例的情況。 如果瀏覽器被設(shè)計(jì)為多個(gè)瀏覽器實(shí)例共享一個(gè)HTTP會(huì)話，則依然能夠應(yīng)用本發(fā)明。此外，雖然在上面示出的實(shí)施方式中，結(jié)合IFrame對(duì)本明進(jìn)行了詳細(xì)描述，這只 是出于說(shuō)明的目的。實(shí)際上，本發(fā)明并不僅限于IFrame，本發(fā)明還可以應(yīng)用于具有例如選項(xiàng) 卡等任何其他適當(dāng)?shù)挠脩艚涌诮M件的環(huán)境中。利用本發(fā)明的方法，通過(guò)將訪問(wèn)同一應(yīng)用的不同實(shí)例的HTTP請(qǐng)求的域名部分修 改為新的域名，實(shí)現(xiàn)了對(duì)現(xiàn)有技術(shù)中的HTTP會(huì)話的隔離，從而得到了與各個(gè)服務(wù)實(shí)例對(duì)應(yīng) 的子會(huì)話。在與服務(wù)器進(jìn)行通信時(shí)，各個(gè)服務(wù)實(shí)例使用與其對(duì)應(yīng)的HTTP子會(huì)話，從而使得 服務(wù)器能夠通過(guò)各個(gè)HTTP會(huì)話標(biāo)識(shí)識(shí)別出各個(gè)服務(wù)實(shí)例，進(jìn)而確保了數(shù)據(jù)的正確性，避免 了現(xiàn)有技術(shù)中引起的混淆，并且這對(duì)于用戶是透明的，從而帶來(lái)了良好的用戶體驗(yàn)，更好地 滿足了商業(yè)的需求。通過(guò)以上對(duì)具體實(shí)施例的描述，本領(lǐng)域技術(shù)人員可以理解，上述的系統(tǒng)、裝置和方 法可以使用計(jì)算機(jī)可執(zhí)行指令和/或包含在處理器控制代碼中來(lái)實(shí)現(xiàn)，例如在諸如磁盤(pán)、 CD或DVD-ROM的載體介質(zhì)、諸如只讀存儲(chǔ)器(固件)的可編程的存儲(chǔ)器或者諸如光學(xué)或電 子信號(hào)載體的數(shù)據(jù)載體上提供了這樣的代碼。本實(shí)施例的裝置、服務(wù)器及其單元可以由諸 如超大規(guī)模集成電路或門(mén)陣列、諸如邏輯芯片、晶體管等的半導(dǎo)體、或者諸如現(xiàn)場(chǎng)可編程門(mén) 陣列、可編程邏輯設(shè)備等的可編程硬件設(shè)備的硬件電路實(shí)現(xiàn)，也可以用由各種類型的處理 器執(zhí)行的軟件實(shí)現(xiàn)，也可以由上述硬件電路和軟件的結(jié)合實(shí)現(xiàn)。雖然以上結(jié)合具體實(shí)施例，對(duì)本發(fā)明的利用遠(yuǎn)程應(yīng)用處理本地文件的系統(tǒng)及方法 進(jìn)行了詳細(xì)描述，但本發(fā)明并不限于此。本領(lǐng)域普通技術(shù)人員能夠在說(shuō)明書(shū)教導(dǎo)之下對(duì)本 發(fā)明進(jìn)行多種變換、替換和修改而不偏離本發(fā)明的精神和范圍。應(yīng)該理解，所有這樣的變 化、替換、修改仍然落入本發(fā)明的保護(hù)范圍之內(nèi)。本發(fā)明的保護(hù)范圍由所附權(quán)利要求來(lái)限定。
權(quán)利要求
1.一種用于處理超文本傳輸協(xié)議HTTP請(qǐng)求的方法，包括接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求；如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同，將所述原始HTTP請(qǐng)求 要訪問(wèn)的域名修改為與所述應(yīng)用的域名不同的新域名，以生成要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪 問(wèn)的新的HTTP請(qǐng)求，并且將所述新的HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的 實(shí)例進(jìn)行訪問(wèn)，其中所述原始HTTP請(qǐng)求要訪問(wèn)的域名和所述新域名對(duì)應(yīng)于相同的IP地址。
2.如權(quán)利要求1所述的方法，還包括如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng) 用的域名不同，直接將所述原始HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例 進(jìn)行訪問(wèn)。
3.如權(quán)利要求1或2所述的方法，還包括將所述新的HTTP請(qǐng)求返回至發(fā)出所述原始 HTTP請(qǐng)求的客戶端。
4.如權(quán)利要求1或2所述的方法，還包括獲取所述原始HTTP請(qǐng)求的URL，并分析所獲 取的URL中的域名部分以判斷所述原始HTTP請(qǐng)求要訪問(wèn)的域名是否與所述應(yīng)用的域名相 同。
5.如權(quán)利要求4所述的方法，如果所獲取的URL中的域名部分與預(yù)定義的應(yīng)用域名列 表中的域名相同，則確定所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同。
6.如權(quán)利要求4所述的方法，如果所獲取的URL中的域名部分的模式與預(yù)定義的新域 名模式不同，則確定所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同。
7.如權(quán)利要求1-6任一所述的方法，其中將所述原始HTTP請(qǐng)求要訪問(wèn)的域名修改為與 所述應(yīng)用的域名不同的新域名包括向所述原始HTTP請(qǐng)求的URL的頭部加入隨機(jī)產(chǎn)生的符 號(hào)。
8.如權(quán)利要求7所述的方法，所述隨機(jī)產(chǎn)生的符號(hào)符合預(yù)定義的新域名模式。
9.如權(quán)利要求1-8任一所述的方法，還包括記錄如下內(nèi)容所述新域名、根據(jù)所述新域 名對(duì)所述應(yīng)用進(jìn)行最后一次訪問(wèn)的時(shí)間以及將所述新域名設(shè)置為無(wú)效域名的時(shí)間期限。
10.如權(quán)利要求9所述的方法，還包括根據(jù)所記錄的最后一次訪問(wèn)的時(shí)間和所記錄的 時(shí)間期限，判斷是否保持當(dāng)前接收到的新域名有效，如果判斷結(jié)果為否，將所述當(dāng)前接收到 的新域名視為與所述應(yīng)用的域名相同的原始域名。
11.如權(quán)利要求1-10任一所述的方法，對(duì)于請(qǐng)求對(duì)同一應(yīng)用的不同實(shí)例進(jìn)行訪問(wèn)的不 同的原始HTTP請(qǐng)求，所修改得到的新域名各不相同，其中不同的原始HTTP請(qǐng)求要訪問(wèn)的域 名與所述同一應(yīng)用的域名相同。
12.如權(quán)利要求1-11任一所述的方法，所述應(yīng)用是軟件即服務(wù)應(yīng)用。
13.一種用于處理超文本傳輸協(xié)議HTTP請(qǐng)求的系統(tǒng)，包括接收模塊，用于接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求；修改模塊，被配置為如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同，將 所述原始HTTP請(qǐng)求要訪問(wèn)的域名修改為與所述應(yīng)用的域名不同的新域名，以生成要對(duì)所 述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求；以及發(fā)送模塊，被配置為將所述新的HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的 實(shí)例進(jìn)行訪問(wèn)，其中所述原始HTTP請(qǐng)求要訪問(wèn)的域名和所述新域名對(duì)應(yīng)于相同的IP地址。
14.如權(quán)利要求13所述的系統(tǒng)，所述發(fā)送模塊還被配置為如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名不同，直接將所述原始HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以 對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)。
15.如權(quán)利要求13或14所述的系統(tǒng)，還包括返回模塊，被配置為將所述新的HTTP請(qǐng)求 返回至發(fā)出所述原始HTTP請(qǐng)求的客戶端。
16.如權(quán)利要求13或14所述的系統(tǒng)，還包括判斷模塊，用于獲取所述原始HTTP請(qǐng)求 的URL，并分析所獲取的URL中的域名部分以判斷所述原始HTTP請(qǐng)求要訪問(wèn)的域名是否與 所述應(yīng)用的域名相同。
17.如權(quán)利要求16所述的系統(tǒng)，所述判斷模塊被進(jìn)一步配置為如果所獲取的URL中 的域名部分與預(yù)定義的應(yīng)用域名列表中的域名相同，則確定所述原始HTTP請(qǐng)求要訪問(wèn)的 域名與所述應(yīng)用的域名相同。
18.如權(quán)利要求16所述的系統(tǒng)，所述判斷模塊被進(jìn)一步配置為如果所獲取的URL中 的域名部分的模式與預(yù)定義的新域名模式不同，則確定所述原始HTTP請(qǐng)求要訪問(wèn)的域名 與所述應(yīng)用的域名相同。
19.如權(quán)利要求13-18任一所述的系統(tǒng)，所述修改模塊被進(jìn)一步配置為通過(guò)向所述原 始HTTP請(qǐng)求的URL的頭部加入隨機(jī)產(chǎn)生的符號(hào)，來(lái)將所述原始HTTP請(qǐng)求要訪問(wèn)的域名修 改為與所述應(yīng)用的域名不同的新域名。
20.如權(quán)利要求19所述的系統(tǒng)，所述隨機(jī)產(chǎn)生的符號(hào)符合預(yù)定義的新域名模式。
21.如權(quán)利要求13-20任一所述的系統(tǒng)，還包括記錄模塊，被配置為記錄如下內(nèi)容所 述新域名、根據(jù)所述新域名對(duì)所述應(yīng)用進(jìn)行最后一次訪問(wèn)的時(shí)間以及將所述新域名設(shè)置為 無(wú)效域名的時(shí)間期限。
22.如權(quán)利要求21所述的系統(tǒng)，所述判斷模塊被進(jìn)一步配置為根據(jù)所記錄的最后一 次訪問(wèn)的時(shí)間和所記錄的時(shí)間期限，判斷是否保持當(dāng)前接收到的新域名有效，如果判斷結(jié) 果為否，將所述當(dāng)前接收到的新域名視為與所述應(yīng)用的域名相同的原始域名。
23.如權(quán)利要求13-22任一所述的系統(tǒng)，所述修改模塊被進(jìn)一步配置為對(duì)于請(qǐng)求對(duì)同 一應(yīng)用的不同實(shí)例進(jìn)行訪問(wèn)的不同的原始HTTP請(qǐng)求，所修改得到的新域名各不相同，其中 不同的原始HTTP請(qǐng)求要訪問(wèn)的域名與所述同一應(yīng)用的域名相同。
24.如權(quán)利要求13-23任一所述的系統(tǒng)，所述應(yīng)用是軟件即服務(wù)應(yīng)用。
全文摘要
本發(fā)明涉及超文本傳輸協(xié)議(HTTP，Hypertext Transfer Protocol)會(huì)話技術(shù)，尤其涉及用于處理HTTP請(qǐng)求的方法和系統(tǒng)。本發(fā)明提供了一種用于處理HTTP請(qǐng)求的方法，包括接收要對(duì)應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的原始HTTP請(qǐng)求；如果所述原始HTTP請(qǐng)求要訪問(wèn)的域名與所述應(yīng)用的域名相同，將所述原始HTTP請(qǐng)求要訪問(wèn)的域名修改為與所述應(yīng)用的域名不同的新域名，以生成要對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)的新的HTTP請(qǐng)求，并且將所述新的HTTP請(qǐng)求發(fā)送至所述應(yīng)用的服務(wù)器以對(duì)所述應(yīng)用的實(shí)例進(jìn)行訪問(wèn)，其中所述原始HTTP請(qǐng)求要訪問(wèn)的域名和所述新域名對(duì)應(yīng)于相同的IP地址。從而避免現(xiàn)有技術(shù)中在同一超文本傳輸協(xié)議會(huì)話中運(yùn)行同一應(yīng)用的多個(gè)服務(wù)實(shí)例時(shí)出現(xiàn)的諸如數(shù)據(jù)混淆、數(shù)據(jù)錯(cuò)誤、使用不便等各種問(wèn)題。
文檔編號(hào)H04L29/08GK101997903SQ20091017095
公開(kāi)日2011年3月30日 申請(qǐng)日期2009年8月27日 優(yōu)先權(quán)日2009年8月27日
發(fā)明者向哲, 崔潔, 張劍鳴, 王斌 申請(qǐng)人:國(guó)際商業(yè)機(jī)器公司