本申請涉及互聯(lián)網(wǎng)數(shù)據(jù)處理技術(shù)領(lǐng)域，特別涉及超文本傳輸協(xié)議請求的處理方法及裝置。

背景技術(shù)：

目前，用戶在通過HTTP(超文本傳輸協(xié)議，HyperText Transfer Protocol)請求向服務(wù)器請求服務(wù)器資源時，需要將用戶的請求信息攜帶在HTTP請求中發(fā)送給服務(wù)器。服務(wù)器可能會在某個時間段或者時間點同時接收大量的HTTP請求，那么為了防止HTTP請求量的突增導(dǎo)致系統(tǒng)的不穩(wěn)定或用戶體驗的整體變差，可以需要將用戶導(dǎo)向至等待頁面，在用戶等待一段時間后，再重新為用戶提供HTTP請求的處理服務(wù)。

技術(shù)實現(xiàn)要素：

但是發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)存在以下技術(shù)問題：

在等待頁面結(jié)束等待之后，客戶端向用戶重新提供的頁面是根據(jù)從等待頁面中獲取到的原始參數(shù)而生成的原始頁面。例如，用戶已經(jīng)在原始頁面的輸入框中輸入了登錄名和密碼并觸發(fā)了登錄請求，但是一旦客戶端接收到等待頁面并結(jié)束等待之后，再次向用戶展示的就是輸入框依然空白的原始頁面，用戶在提交登錄請求之后輸入的登錄名和密碼信息都丟失了。這就使得用戶需要重新在原始頁面中輸入請求信息，如果因為服務(wù)器的性能多次向客戶端返回了等待頁面，那么就需要用戶多次輸入請求信息，這無疑會增加HTTP請求處理過程中客戶端與服務(wù)器的交互次數(shù)，同時也過多或者不必要地消耗了服務(wù)器的系統(tǒng)資源。進一步的，也給用戶訪問服務(wù)器帶來不好的感受和體驗。

本申請所要解決的技術(shù)問題是提供超文本傳輸協(xié)議請求的處理方法，用以盡量避免現(xiàn)有技術(shù)中在服務(wù)器返回等待頁面的情況下需要用戶 多次輸入請求信息的現(xiàn)象，從而減少HTTP請求處理過程中客戶端與服務(wù)器的交互次數(shù)，同時節(jié)約了服務(wù)器的系統(tǒng)資源。進一步的，還能提升用戶訪問服務(wù)器的感受和體驗。

本申請還提供了超文本傳輸協(xié)議請求的處理裝置，用以保證上述方法在實際中的實現(xiàn)及應(yīng)用。

為了解決上述問題，本申請公開了一種超文本傳輸協(xié)議請求的處理方法，該方法應(yīng)用于服務(wù)器端，包括：

響應(yīng)于用戶通過客戶端提交的超文本傳輸協(xié)議HTTP請求，獲取HTTP請求中攜帶的請求信息；

在所述HTTP請求需要被等待的情況下，依據(jù)所述請求信息生成標簽表單；其中，所述標簽表單的表單項包括所述請求信息；

將嵌入了所述標簽表單的等待頁面返回至所述客戶端，以便所述客戶端在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

本申請公開了一種超文本傳輸協(xié)議請求的處理方法，該方法應(yīng)用于客戶端，包括：

響應(yīng)于用戶觸發(fā)的請求信息，將包括所述請求信息的超文本傳輸協(xié)議HTTP請求發(fā)送至服務(wù)器；

接收服務(wù)器返回的、嵌入了標簽表單的等待頁面以供顯示；其中，所述標簽表單為：在所述HTTP請求需要被等待的情況下，服務(wù)器依據(jù)所述請求信息生成的標簽表單，所述標簽表單的表單項包括所述請求信息；

在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

本申請公開了一種超文本傳輸協(xié)議請求的處理裝置，該裝置集成于服務(wù)器上，包括：

獲取模塊，用于響應(yīng)于用戶通過客戶端提交的超文本傳輸協(xié)議HTTP請求，獲取HTTP請求中攜帶的請求信息；

生成模塊，用于在所述HTTP請求需要被等待的情況下，依據(jù)所述請求信息生成標簽表單；其中，所述標簽表單的表單項包括所述請求信息；

返回等待頁面模塊，用于將嵌入了所述標簽表單的等待頁面返回至所述客戶端，以便所述客戶端在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

本申請公開了一種超文本傳輸協(xié)議請求的處理裝置，該裝置集成于客戶端上，包括：

發(fā)送模塊，用于響應(yīng)于用戶觸發(fā)的請求信息，將包括所述請求信息的超文本傳輸協(xié)議HTTP請求發(fā)送至服務(wù)器；

接收等待頁面模塊，用于接收服務(wù)器返回的、嵌入了標簽表單的等待頁面以供顯示；其中，所述標簽表單為：在所述HTTP請求需要被等待的情況下，服務(wù)器依據(jù)所述請求信息生成的標簽表單，所述標簽表單的表單項包括所述請求信息；

提交模塊，用于在預(yù)設(shè)的等待時間到來的情況下，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

與現(xiàn)有技術(shù)相比，本申請包括以下優(yōu)點：

在本申請實施例中，在用戶提交的HTTP請求被等待處理時，無需用戶再次在輸入框中輸入請求信息，而是由客戶端根據(jù)等待頁面中嵌入的form表單，重新提交包括請求信息的HTTP請求，直至服務(wù)器成功處理該HTTP請求。因此，本申請實施例可以減少客戶端與服務(wù)端交互所帶來的系統(tǒng)資源消耗，同時也避免了用戶多次輸入相同的請求信息，并且用戶在瀏覽器中的URL(統(tǒng)一資源定位符，Uniform Resoure Locator)也是沒有變化的，進一步提升了用戶體驗。

本申請實施例還可以避免客戶端對于用戶觸發(fā)的HTTP請求進入無限等待的現(xiàn)象，從而可以釋放掉客戶端本次提交的HTTP請求所占用的系統(tǒng)資源，并且這種及時將處理結(jié)果告知用戶的方式也能進一步提升用戶體驗。

當然，實施本申請的任一產(chǎn)品并不一定需要同時達到以上所述的所有優(yōu)點。

附圖說明

為了更清楚地說明本申請實施例中的技術(shù)方案，下面將對實施例描述 中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本申請的超文本傳輸協(xié)議請求的處理方法實施例1的流程圖；

圖2是本申請的HTTP請求的一種格式示意圖；

圖3是本申請中一種用戶在地址欄發(fā)起HTTP請求的界面示意圖；

圖4是本申請中用戶通過在輸入框輸入信息并點擊相應(yīng)的按鈕來提交HTTP請求的界面示意圖；

圖5是本申請中一個簡單的form表單的示例性示意圖；

圖6為本申請中一個等待頁面的示例性示意圖；

圖7為本申請的超文本傳輸協(xié)議請求的處理方法實施例2的流程圖；

圖8為本申請的超文本傳輸協(xié)議請求的處理裝置實施例1的結(jié)構(gòu)框圖；

圖9為本申請的超文本傳輸協(xié)議請求的處理裝置實施例2的結(jié)構(gòu)框圖。

具體實施方式

下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

本申請可用于眾多通用或?qū)Ｓ玫挠嬎阊b置環(huán)境或配置中。例如：個人計算機、服務(wù)器計算機、手持設(shè)備或便攜式設(shè)備、平板型設(shè)備、多處理器裝置、包括以上任何裝置或設(shè)備的分布式計算環(huán)境等等。

本申請可以在由計算機執(zhí)行的計算機可執(zhí)行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執(zhí)行特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等等。也可以在分布式計算環(huán)境中實踐本申請，在這些分布式計算環(huán)境中，由通過通信網(wǎng)絡(luò)而被連接的遠程處理設(shè)備來執(zhí)行任務(wù)。在分布式計算環(huán)境中，程序模塊 可以位于包括存儲設(shè)備在內(nèi)的本地和遠程計算機存儲介質(zhì)中。

參考圖1，示出了本申請的超文本傳輸協(xié)議請求的處理方法實施例1的流程圖，該方法可以應(yīng)用于服務(wù)器端，本實施例可以包括以下步驟：

步驟101：響應(yīng)于用戶通過客戶端提交的HTTP請求，獲取HTTP請求中攜帶的請求信息。

在本實施例中，用戶可以通過客戶端來向服務(wù)器提交HTTP請求，在該HTTP請求中攜帶了請求信息，例如用戶希望訪問的網(wǎng)頁地址信息，或者用戶輸入的登錄名和登錄密碼的信息等。其中，HTTP請求可以包括獲取(GET)請求與發(fā)送(POST)請求，這兩種請求都可以將請求信息通過請求參數(shù)的方式發(fā)送給服務(wù)器。但是這兩種請求參數(shù)的攜帶方式有所不同，GET請求的方式只能將請求信息放在URL里，而POST請求則不僅可以將請求信息放在URL里，也可以通過自己的請求體來傳遞參數(shù)。

為了方便本領(lǐng)域技術(shù)人員對這兩種HTTP請求有更清楚的了解，下面參考附圖對其進行詳細說明。參考圖2所示，為HTTP請求的格式示意圖。在HTTP請求中，第一行為請求行(request line)，用來表示請求類型(例如是GET請求還是POST請求等)、URL(用戶請求訪問的網(wǎng)頁地址)和HTTP版本。第二行是請求頭(request headers)，請求頭部分的每一行都可以表示一個請求頭，并且請求頭以一個空行(blank line)來結(jié)束請求。在空行(blank line)后面會有請求體(request-body)，不過請求體僅存在于部分HTTP請求類型之中，例如POST請求類型。

針對GET請求來說，GET請求沒有請求體，因此，請求信息是作為URL的一部分被傳送到服務(wù)端。由于URL有長度限制，GET請求所能攜帶的請求信息的大小是有限制的，并且因為GET請求的請求信息會直接出現(xiàn)在地址欄中作為URL的一部分傳送給服務(wù)器，所以當需要傳遞比較少的數(shù)據(jù)或者安全性要求不太高的請求信息可以通過GET請求傳送給服務(wù)器。而POST請求會有請求體，因此請求信息可以放在請求體中被傳送到服務(wù)器。PST請求可以傳送較多的數(shù)據(jù)或者安全性要求比較高的數(shù)據(jù)，例如用戶登陸請求，用戶輸入的用戶名與密碼就可以通過POST請求傳遞 到服務(wù)器。

參考圖3所示，為一種HTTP請求發(fā)起的界面示意圖。在圖3中，用戶直接在地址欄輸入了目標URL進行訪問，其中請求信息“q”的值是“test”，該請求信息作為URL的一部分向服務(wù)器傳送。可以理解的是，如果是用戶直接輸入URL提交的HTTP請求，則這種請求的請求類型只能是GET請求。再參考圖4所示，為用戶通過在輸入框輸入信息并點擊相應(yīng)的按鈕來提交HTTP請求的界面示意圖。在圖4中，用戶點擊相應(yīng)的按鈕之后，如果是GET請求，則請求信息可以通過URL的方式提交給服務(wù)器，而如果是POST請求，則請求信息可以包含在請求體中提交給服務(wù)器。因此，對于用戶通過填寫輸入框控件等非輸入URL的方式來提交HTTP請求時，該HTTP既可以是GET請求，也可以是POST請求。

接著返回圖1，進入步驟102：在所述HTTP請求需要被等待的情況下，依據(jù)所述請求信息生成標簽表單；其中，所述標簽表單的表單項包括所述請求信息。

在HTTP通過客戶端(例如通過客戶端的瀏覽器)提交給服務(wù)器的情況下，服務(wù)器可以先判斷該HTTP請求是否需要被等待處理。具體的，服務(wù)器可以根據(jù)系統(tǒng)負載，例如CPU利用率，內(nèi)存利用率等參數(shù)，利用負載均衡原理來判斷該HTTP請求可以被立即處理，還是需要等待一段時間之后再處理。如果該HTTP請求需要等待被處理，那么，服務(wù)器就根據(jù)HTTP請求中的請求信息來生成標簽(form)表單，其中，表單項的內(nèi)容包括該請求信息。

參考圖5所示，圖5為一個簡單的form表單的示意圖。form表單有兩個重要屬性，行為“action”表示form表單需要提交到的URL(即，用戶請求訪問的目標地址)，方法“method”表示提交form表單時采用的類型(例如POST或者GET)。當form表單的method為GET時，form表單的請求信息會作為URL的一部分提交給服務(wù)器，如：“/login？username＝test&password＝test”，在該URL中，請求信息中的用戶名為“test”，請求信息中的密碼也是“test”。而如果form表單的method為POST，則請求信息會放在POST請求的請求體中傳遞給服務(wù)端，例如， 某個POST請求的請求體為：username＝test&password＝test。

具體的，步驟102在實現(xiàn)時可以包括：

步驟A1：在所述HTTP請求需要被等待的情況下，判斷所述HTTP請求的類型為獲取GET請求還是發(fā)送POST請求，如果是GET請求，則進入步驟A2；如果是POST請求，則進入步驟A3。

服務(wù)器可以根據(jù)請求信息的攜帶方式來判斷當前HTTP請求是GET請求還是POST請求。

步驟A2：生成方法為GET、行為為目標統(tǒng)一資源定位符URL且屬性為隱藏的標簽表單，并從所述目標URL中獲取請求信息作為表單項；其中，所述目標URL為所述HTTP請求指向的地址。

如果是GET請求，則服務(wù)器就生成一個method為GET，action為目標URL的form表單，并將該form表單的屬性設(shè)置為隱藏，同時將從目標URL中獲取到的請求信息作為表單項，目標URL可以為：HTTP請求指向的、用戶需要訪問的目標地址。

步驟A3：生成方法為POST、行為為目標URL且屬性為隱藏的標簽表單，并從POST請求的請求體中獲取請求信息作為表單項。

而如果是POST請求，則服務(wù)器就生成一個method為POST，action為目標URL的form表單，YE將該form表單的屬性設(shè)置為隱藏，同時將從POST請求的請求體中獲取到的請求信息作為表單項。

步驟103：將嵌入了所述標簽表單的等待頁面返回至所述客戶端，以便所述客戶端在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

在實際應(yīng)用中，因為form表單是HTML(超文本標記語言，HyperText Markup Language)頁面的元素，同時本申請實施例中用戶的請求信息都已經(jīng)封裝在form表單中，所以在本步驟中可以將包括了請求信息的form表單嵌入等待頁面中，并將該等待頁面返回給客戶端，因為步驟102中生成的form表單的屬性為隱藏，所以用戶不會在客戶端上呈現(xiàn)的等待頁面中看到form表單。

可以理解的是，服務(wù)器可以設(shè)置一個等待時間，例如3秒鐘，并將該 等待時間預(yù)先設(shè)置在等待頁面的頁面模板中。該等待時間的數(shù)值可以由本領(lǐng)域技術(shù)人員根據(jù)經(jīng)驗值或者服務(wù)器的性能等參數(shù)自主設(shè)置。那么，在服務(wù)器將等待頁面返回至客戶端并展示給用戶之后，客戶端例如展示該等待頁面的瀏覽器就可以根據(jù)服務(wù)器預(yù)先設(shè)置好的等待時間來進行倒計時，并在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器?？蛇x的，還可以將倒計時的具體時間顯示給用戶。

在本實施例中，由于等待頁面中嵌入的form表單的表單項包含有請求信息，并且form表單的action就是用戶原始請求的目標URL，method也是用戶原始請求的請求類型，所以在本步驟中客戶端重新提交的請求信息與步驟101中提交的請求信息是完全一致的。可以理解的是，當包括請求信息的HTTP請求重新提交到服務(wù)器時，服務(wù)器可以接著判斷該HTTP請求是否需要等待處理，即步驟101，直至該HTTP請求被服務(wù)器成功處理。參考圖6所示，為實際應(yīng)用中的一個等待頁面的例子示意圖。

可見，在本實施例中，在用戶提交的HTTP請求被等待處理時，無需用戶再次在輸入框中輸入請求信息，而是由客戶端根據(jù)等待頁面中嵌入的form表單，重新提交包括請求信息的HTTP請求，直至服務(wù)器成功處理該HTTP請求。因此，本申請實施例可以減少客戶端與服務(wù)端交互所帶來的系統(tǒng)資源消耗，同時也避免了用戶多次輸入相同的請求信息，并且用戶在瀏覽器中的URL也是沒有變化的，進一步提升了用戶體驗。

在實際應(yīng)用中，還有一種情況，就是服務(wù)器性能在一段時間內(nèi)都無法正常處理某個HTTP請求，那么服務(wù)器可能就需要向客戶端返回HTTP請求處理失敗的提示信息，因此，本申請實施例中的form表單還可以設(shè)置一個記錄項，用來表示客戶端向服務(wù)器提交同一個HTTP請求的請求信息的次數(shù)。

則在步驟103之后，該方法還可以包括：

步驟104：判斷所述記錄項表示的請求信息的提交次數(shù)是否大于預(yù)設(shè)的提交次數(shù)閾值，如果是，則進入步驟105。

服務(wù)器可以根據(jù)記錄項來判斷對于某個HTTP請求的請求信息的提 交次數(shù)是否大于預(yù)設(shè)的提交次數(shù)閾值，例如已經(jīng)超過5次提交同一個HTTP請求。當然，該提交次數(shù)閾值也可以由本領(lǐng)域技術(shù)人員根據(jù)服務(wù)器的性能和實際需求自主設(shè)置。

步驟105：向所述客戶端返回所述HTTP請求處理失敗的提示信息。

如果客戶端提交了5次HTTP請求都沒有處理成功，那么，服務(wù)器可以不再處理該HTTP請求，并向客戶端返回所述HTTP請求處理失敗的提示信息。這樣就可以避免客戶端對于用戶觸發(fā)的HTTP請求進入無限等待的現(xiàn)象，從而釋放掉客戶端本次提交的HTTP請求所占用的系統(tǒng)資源，并且這種及時將處理結(jié)果告知用戶的方式也進一步提升了用戶體驗。

參考圖7，示出了本申請一種超文本傳輸協(xié)議請求的處理方法實施例2的流程圖，該方法可以應(yīng)用于客戶端，本實施例可以包括以下步驟：

步驟701：響應(yīng)于用戶觸發(fā)的請求信息，將包括所述請求信息的超文本傳輸協(xié)議HTTP請求發(fā)送至服務(wù)器。

本實施例與實施例1的不同之處在于，本實施例是應(yīng)用于客戶端的，例如本實施例的執(zhí)行主體可以為客戶端的瀏覽器等能夠向服務(wù)器提交HTTP請求的裝置。在實際應(yīng)用中，假設(shè)用戶在瀏覽器上觸發(fā)了請求信息，例如包括登錄名稱和登錄密碼的請求信息，或者直接輸入了希望訪問的目標URL的請求信息等，瀏覽器可以將包括該請求信息的HTTP請求發(fā)送給服務(wù)器。

步驟702：接收服務(wù)器返回的、嵌入了標簽表單的等待頁面以供顯示；其中，所述標簽表單為：在所述HTTP請求需要被等待的情況下，服務(wù)器依據(jù)所述請求信息生成的標簽表單，所述標簽表單的表單項包括所述請求信息。

服務(wù)器根據(jù)請求信息生成標簽表單并返回等待頁面的詳細過程可以參考步驟102的論述，在此不再贅述。

步驟703：在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

客戶端可以根據(jù)等待頁面中設(shè)置的等待時間進行倒計時，并在預(yù)設(shè)的 等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

在實際應(yīng)用中，在服務(wù)器端生成的form表單還可以設(shè)置記錄項，用來表示客戶端向服務(wù)器提交同一個HTTP請求的請求信息的次數(shù)，那么服務(wù)器就可以根據(jù)form表單的記錄項判斷某一個HTTP請求的提交次數(shù)是否大于預(yù)設(shè)的提交次數(shù)閾值，如果大于，則所述方法還可以包括：

步驟704：接收服務(wù)器返回的所述HTTP請求處理失敗的提示信息以供顯示；其中，所述提示信息為：服務(wù)器在判斷得到所述記錄項表示的請求信息的提交次數(shù)大于預(yù)設(shè)的提交次數(shù)閾值的情況下返回的。

在服務(wù)器在判斷得到記錄項表示的請求信息的提交次數(shù)大于預(yù)設(shè)的提交次數(shù)閾值的情況下，會向客戶端返回一個HTTP請求處理失敗的提示信息，客戶端可以將該提示信息進行展示，以告知用戶該HTTP請求的處理失敗。

可見，在本實施例中，在用戶提交的HTTP請求被等待處理時，無需用戶再次在輸入框中輸入請求信息，而是由客戶端根據(jù)服務(wù)器返回的等待頁面中嵌入的form表單，重新提交包括請求信息的HTTP請求，直至服務(wù)器成功處理該HTTP請求。因此，本申請實施例可以減少客戶端與服務(wù)端交互所帶來的系統(tǒng)資源消耗，同時也避免了用戶多次輸入相同的請求信息，并且用戶在瀏覽器中的URL也是沒有變化的，進一步提升了用戶體驗。

進一步的，服務(wù)器還可以返回HTTP請求處理失敗的提示信息，以避免客戶端對于用戶觸發(fā)的HTTP請求進入無限等待的現(xiàn)象，從而釋放掉客戶端本次提交的HTTP請求所占用的系統(tǒng)資源，并且這種及時將處理結(jié)果告知用戶的方式也進一步提升了用戶體驗。

對于前述的方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領(lǐng)域技術(shù)人員應(yīng)該知悉，本申請并不受所描述的動作順序的限制，因為依據(jù)本申請，某些步驟可以采用其他順序或者同時進行。其次，本領(lǐng)域技術(shù)人員也應(yīng)該知悉，說明書中所描述的實施例均屬于優(yōu)選實施例，所涉及的動作和模塊并不一定是本申請所必須的。

與上述本申請的超文本傳輸協(xié)議請求的處理方法實施例1所提供的方法相對應(yīng)，參見圖8，本申請還提供了一種超文本傳輸協(xié)議請求的處理裝置實施例，在本實施例中，該裝置可以集成于服務(wù)器上，該裝置可以包括：

獲取模塊801，用于響應(yīng)于用戶通過客戶端提交的超文本傳輸協(xié)議HTTP請求，獲取HTTP請求中攜帶的請求信息。

生成模塊802，用于在所述HTTP請求需要被等待的情況下，依據(jù)所述請求信息生成標簽表單；其中，所述標簽表單的表單項包括所述請求信息。

其中，生成模塊802具體可以包括：

判斷子模塊，用于在所述HTTP請求需要被等待的情況下，判斷所述HTTP請求的類型為獲取GET請求還是發(fā)送POST請求；第一生成子模塊，用于在所述HTTP請求為GET請求的情況下，生成方法為GET、行為為目標統(tǒng)一資源定位符URL且屬性為隱藏的標簽表單；第一獲取子模塊，用于在所述HTTP請求為GET請求HTTP請求為，從所述目標URL中獲取請求信息作為表單項；其中，所述目標URL為所述HTTP請求指向的地址；第二生成子模塊，用于在所述HTTP請求為POST請求的情況下，生成方法為POST、行為為目標URL且屬性為隱藏的標簽表單；和，第二獲取子模塊，用于在所述HTTP請求為POST請求的情況下，從POST請求的請求體中獲取請求信息作為表單項。

返回等待頁面模塊803，用于將嵌入了所述標簽表單的等待頁面返回至所述客戶端，以便所述客戶端在預(yù)設(shè)的等待時間到來時，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

在實際應(yīng)用中，標簽表單還設(shè)置有記錄項，所述記錄項用于表示所述客戶端向服務(wù)器提交同一個HTTP請求的請求信息的次數(shù)；則所述裝置還可以包括：

判斷模塊804，用于判斷所述記錄項表示的請求信息的提交次數(shù)是否大于預(yù)設(shè)的提交次數(shù)閾值；

返回提示信息模塊805，用于在所述判斷模塊的結(jié)果為是的情況下，向所述客戶端返回所述HTTP請求處理失敗的提示信息。

可見，在本實施例中，在用戶提交的HTTP請求被等待處理時，無需用戶再次在輸入框中輸入請求信息，而是由客戶端根據(jù)等待頁面中嵌入的form表單，重新提交包括請求信息的HTTP請求，直至服務(wù)器成功處理該HTTP請求。因此，本申請實施例可以減少客戶端與服務(wù)端交互所帶來的系統(tǒng)資源消耗，同時也避免了用戶多次輸入相同的請求信息，并且用戶在瀏覽器中的URL也是沒有變化的，進一步提升了用戶體驗。

與上述本申請的超文本傳輸協(xié)議請求的處理方法實施例2所提供的方法相對應(yīng)，參見圖9，本申請還提供了一種超文本傳輸協(xié)議請求的處理裝置實施例，在本實施例中，該裝置可以集成于客戶端上，該裝置可以包括：

發(fā)送模塊901，用于響應(yīng)于用戶觸發(fā)的請求信息，將包括所述請求信息的超文本傳輸協(xié)議HTTP請求發(fā)送至服務(wù)器。

接收等待頁面模塊902，用于接收服務(wù)器返回的、嵌入了標簽表單的等待頁面以供顯示；其中，所述標簽表單為：在所述HTTP請求需要被等待的情況下，服務(wù)器依據(jù)所述請求信息生成的標簽表單，所述標簽表單的表單項包括所述請求信息。

提交模塊903，用于在預(yù)設(shè)的等待時間到來的情況下，重新將所述標簽表單中包括的請求信息提交給服務(wù)器。

其中，所述標簽表單還可以設(shè)置有記錄項，所述記錄項用于表示所述客戶端向服務(wù)器提交同一個HTTP請求的請求信息的次數(shù)；則所述裝置還可以包括：

接收提示信息模塊904，用于接收服務(wù)器返回的所述HTTP請求處理失敗的提示信息以供顯示；其中，所述提示信息為：服務(wù)器在判斷得到所述記錄項表示的請求信息的提交次數(shù)大于預(yù)設(shè)的提交次數(shù)閾值的情況下返回的。

可見，在本實施例中，在用戶提交的HTTP請求被等待處理時，無需 用戶再次在輸入框中輸入請求信息，而是由客戶端根據(jù)服務(wù)器返回的等待頁面中嵌入的form表單，重新提交包括請求信息的HTTP請求，直至服務(wù)器成功處理該HTTP請求。因此，本申請實施例可以減少客戶端與服務(wù)端交互所帶來的系統(tǒng)資源消耗，同時也避免了用戶多次輸入相同的請求信息，并且用戶在瀏覽器中的URL也是沒有變化的，進一步提升了用戶體驗。

進一步的，服務(wù)器還可以返回HTTP請求處理失敗的提示信息，以避免客戶端對于用戶觸發(fā)的HTTP請求進入無限等待的現(xiàn)象，從而釋放掉客戶端本次提交的HTTP請求所占用的系統(tǒng)資源，并且這種及時將處理結(jié)果告知用戶的方式也進一步提升了用戶體驗。

需要說明的是，本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。對于裝置類實施例而言，由于其與方法實施例基本相似，所以描述的比較簡單，相關(guān)之處參見方法實施例的部分說明即可。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

以上對本申請所提供的超文本傳輸協(xié)議請求的處理方法及裝置進行了詳細介紹，本文中應(yīng)用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本申請的思想，在具體實施方 式及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對本申請的限制。