報文處理方法及裝置的制造方法
【專利摘要】本申請?zhí)峁┮环N報文處理方法及裝置，該方法包括：分別與客戶端和服務(wù)端建立連接；截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所述服務(wù)端的地址信息；解析所述請求報文的請求行中包含的請求方法字段；當所述請求方法字段中記錄的請求方式為第一類型時，對所述請求報文進行請求參數(shù)替換處理，得到匹配于第二類型的修改后請求報文；將所述修改后請求報文發(fā)送至所述服務(wù)端。通過本申請的技術(shù)方案，可以使用戶采用自己更加習慣、效率更高的報文類型，并基于對報文類型的自動轉(zhuǎn)換，確保服務(wù)端的正確響應(yīng)。
【專利說明】
報文處理方法及裝置
技術(shù)領(lǐng)域
[0001] 本申請涉及報文傳輸技術(shù)領(lǐng)域，尤其涉及報文處理方法及裝置。
【背景技術(shù)】
[0002] 在客戶端與服務(wù)端之間的交互過程中，客戶端通過向服務(wù)端發(fā)送請求報文，實現(xiàn) 客戶端對服務(wù)端的數(shù)據(jù)傳達，或者客戶端還可以從服務(wù)端獲取對應(yīng)的響應(yīng)數(shù)據(jù)。
[0003] 然而，在既定的應(yīng)用場景中，服務(wù)端對來自客戶端的請求報文存在一定的要求，BP 該請求報文應(yīng)當采用某個或某些固定類型的請求方式，否則將無法正確識別和響應(yīng)該請求 報文。

【發(fā)明內(nèi)容】

[0004] 有鑒于此，本申請?zhí)峁┮环N報文處理方法及裝置，可以解決相關(guān)技術(shù)中的不足。
[0005] 為實現(xiàn)上述目的，本申請?zhí)峁┘夹g(shù)方案如下：
[0006] 根據(jù)本申請的第一方面，提出了一種報文處理方法，包括：
[0007] 分別與客戶端和服務(wù)端建立連接；
[0008] 截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所述服務(wù)端的地址 信息；
[0009] 解析所述請求報文的請求行中包含的請求方法字段；
[0010] 當所述請求方法字段中記錄的請求方式為第一類型時，對所述請求報文進行請求 參數(shù)替換處理，得到匹配于第二類型的修改后請求報文；
[0011] 將所述修改后請求報文發(fā)送至所述服務(wù)端。
[0012] 根據(jù)本申請的第二方面，提出了一種報文處理裝置，包括：
[0013] 連接建立單元，分別與客戶端和服務(wù)端建立連接；
[0014] 報文截獲單元，截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所 述服務(wù)端的地址信息；
[0015] 報文解析單元，解析所述請求報文的請求行中包含的請求方法字段；
[0016] 替換處理單元，當所述請求方法字段中記錄的請求方式為第一類型時，對所述請 求報文進行請求參數(shù)替換處理，得到匹配于第二類型的修改后請求報文；
[0017] 第一報文發(fā)送單元，將所述修改后請求報文發(fā)送至所述服務(wù)端。
[0018] 由以上技術(shù)方案可見，本申請通過對請求報文執(zhí)行自動化的請求參數(shù)替換處理， 使得無論服務(wù)端對請求報文的請求方式（或報文類型）存在任何要求，用戶均可以采用自 己習慣采用、效率更高的請求方式來生成請求報文，并通過上述的請求參數(shù)替換處理來實 現(xiàn)請求方式的自動轉(zhuǎn)換，從而滿足服務(wù)端的上述要求，確保服務(wù)端能夠?qū)崿F(xiàn)正確響應(yīng)。
【附圖說明】
[0019] 圖1是相關(guān)技術(shù)中的報文傳輸?shù)膽?yīng)用場景示意圖；
[0020] 圖2是根據(jù)本申請一示例性實施例中的一種報文處理方法的流程圖；
[0021] 圖3是根據(jù)本申請一示例性實施例中的報文傳輸?shù)膽?yīng)用場景示意圖；
[0022] 圖4是根據(jù)本申請一示例性實施例中的另一種報文處理方法的流程圖；
[0023] 圖5是根據(jù)本申請一示例性實施例中的又一種報文處理方法的流程圖；
[0024] 圖6是根據(jù)本申請一不例性實施例中的一種電子設(shè)備的結(jié)構(gòu)不意圖；
[0025] 圖7是根據(jù)本申請一示例性實施例中的一種報文處理裝置的框圖。
【具體實施方式】
[0026] 圖1是相關(guān)技術(shù)中的報文傳輸?shù)膽?yīng)用場景示意圖，如圖1所示，在相關(guān)技術(shù)中的報 文傳輸是在客戶端與服務(wù)端之間直接完成；或者，在客戶端與服務(wù)端之間可能配置有代理 服務(wù)器，但代理服務(wù)器并不對客戶端和服務(wù)端發(fā)送的報文進行修改，相當于在客戶端與服 務(wù)端之間直接實現(xiàn)報文傳輸。
[0027] 在既定的應(yīng)用場景下，服務(wù)端只能夠?qū)δ硞€或某些固定類型的請求方式進行正確 響應(yīng)。舉例而言，假定服務(wù)端僅能夠?qū)OST方式的請求報文進行正確響應(yīng)，而當客戶端發(fā) 出其他請求方式的請求報文時，比如GET方式的請求報文，則將導(dǎo)致服務(wù)端無法正確地對 請求報文進行識別和響應(yīng)。
[0028] 然而，以POST方式與GET方式為例，當請求報文采用GET方式時，只需要將待傳輸 參數(shù)輸入URL并進行訪問即可，操作簡單、高效；而當請求報文采用POST方式時，則需要涉 及到代碼修改、頁面表單渲染等處理，過程繁瑣、耗時。
[0029] 因此，本申請通過提出一種報文處理方法及裝置，可以同時滿足客戶端的簡單、高 效操作，以及服務(wù)端對請求報文的正確解析與響應(yīng)。為對本申請進行進一步說明，提供下列 實施例：
[0030] 圖2是根據(jù)本申請一示例性實施例中的一種報文處理方法的流程圖，如圖2所示， 該方法應(yīng)用于代理服務(wù)器，可以包括以下步驟：
[0031] 步驟202,分別與客戶端和服務(wù)端建立連接。
[0032] 步驟204,截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所述服務(wù) 端的地址信息。
[0033] 步驟206,解析所述請求報文的請求行中包含的請求方法字段。
[0034] 在本實施例中，當所述請求方法字段中記錄的請求方式為第一類型時，可以判斷 所述請求報文中是否包含對應(yīng)于第二類型的標識參數(shù)，若包含，則對所述請求報文進行請 求參數(shù)替換處理。那么，通過在第一類型的請求報文中添加對應(yīng)于第二類型的標識參數(shù)，使 得代理服務(wù)器可以準確判定客戶端存在對該請求報文進行類型轉(zhuǎn)換的需求。
[0035] 步驟208,當所述請求方法字段中記錄的請求方式為第一類型時，對所述請求報文 進行請求參數(shù)替換處理，得到匹配于第二類型的修改后請求報文。
[0036] 在本實施例中，在執(zhí)行請求參數(shù)替換處理時，可以包括：將所述請求報文的所述 請求方法字段的內(nèi)容修改為所述第二類型；以及，修改所述請求報文的content-type類 型。其中，當?shù)谝活愋蜑镚ET類型、第二類型為POST類型時，修改后請求報文的內(nèi)容-類型 content-type 屬性的類型為默認編碼類型 application/x-www-form-urlencoded，以使得 窗體數(shù)據(jù)被編碼為名稱/值對。
[0037] 在本實施例中，當截獲的請求報文采用了第二類型時，說明客戶端可能并不了解 代理服務(wù)器提供的"請求參數(shù)替換處理"的功能，可以將請求報文直接轉(zhuǎn)發(fā)至服務(wù)端，并向 客戶端發(fā)送提示信息，該提示信息用于指示所述客戶端向所述服務(wù)端發(fā)送請求方式為第一 類型的請求報文，并在該請求報文中添加所述標識參數(shù)。
[0038] 步驟210,將所述修改后請求報文發(fā)送至所述服務(wù)端。
[0039] 在本實施例中，在將所述修改后的請求報文發(fā)送至所述服務(wù)端之后，若接收所述 服務(wù)端返回的響應(yīng)報文，且所述響應(yīng)報文采用的請求方式為所述第二類型，則還可以將所 述響應(yīng)報文的所述請求方法字段的內(nèi)容修改為所述第一類型，得到匹配于所述第一類型的 修改后響應(yīng)報文；然后，將所述修改后響應(yīng)報文發(fā)送至所述客戶端。
[0040] 由上述實施例可知，本申請通過對請求報文執(zhí)行自動化的請求參數(shù)替換處理，使 得無論服務(wù)端對請求報文的請求方式（或報文類型）存在任何要求，用戶均可以采用自己 習慣采用、效率更高的請求方式來生成請求報文，并通過上述的請求參數(shù)替換處理來實現(xiàn) 請求方式的自動轉(zhuǎn)換，從而滿足服務(wù)端的上述要求，確保服務(wù)端能夠?qū)崿F(xiàn)正確響應(yīng)。
[0041] 圖3是根據(jù)本申請一示例性實施例中的報文傳輸?shù)膽?yīng)用場景示意圖，如圖3所述， 在本申請的技術(shù)方案的應(yīng)用場景中，包含客戶端、代理服務(wù)器和服務(wù)端；其中，客戶端生成 并發(fā)送請求報文，而代理服務(wù)器通過對該請求報文的截獲和修改后，將修改后請求報文發(fā) 送至服務(wù)端，實現(xiàn)客戶端與服務(wù)端之間的報文傳輸和響應(yīng)。具體地，圖4是根據(jù)本申請一示 例性實施例中的另一種報文處理方法的流程圖，該方法可以包括以下步驟：
[0042] 步驟402,客戶端生成請求報文，該請求報文采用的請求方式為第一類型。
[0043] 在本實施例中，作為一示例性實施例，假定第一類型為GET方式，而第二類型為 POST方式。GET方式和POST方式均屬于HTTP(用于舉例，也可以為HTTPS)報文的不同方 式；其中，GET方式直接通過URL(Uniform Resoure Locator，統(tǒng)一資源定位器）發(fā)送請求報 文并提交數(shù)據(jù)，且數(shù)據(jù)直接可見于該URL中；而POST方式則基于表單形式，具體將數(shù)據(jù)包含 在HTTP請求頭部（header)內(nèi)。
[0044] 可見，相比于POST方式，通過GET方式生成請求報文（即HTTP請求報文）的過程 顯然更為簡單、快捷。然而，在一些應(yīng)用場景中，服務(wù)端僅識別POST方式的請求報文，而無 法對GET方式的請求報文做出正確響應(yīng)。
[0045] 因此，在本實施例中，基于本申請?zhí)岢龅募夹g(shù)方案，客戶端可以采用更為簡單高效 的GET方式生成請求報文，并通過后續(xù)步驟確保服務(wù)端的正確響應(yīng)，有助于簡化技術(shù)方案 的實現(xiàn)流程、提升請求效率。
[0046] 步驟404,客戶端向服務(wù)端發(fā)送請求報文。
[0047] 步驟406,代理服務(wù)器截獲客戶端向服務(wù)端發(fā)送的請求報文。
[0048] 在本實施例中，通過對代理服務(wù)器的配置，可以對客戶端與服務(wù)端之間的傳輸報 文進行監(jiān)控，比如當接收到的報文的源地址為客戶端的地址信息、目的地址為服務(wù)端的地 址信息時，就截獲該報文并避免該報文的直接發(fā)送。
[0049] 步驟408,代理服務(wù)器解析請求報文，查看該請求報文的請求方法字段的請求方 式。
[0050] 在本實施例中，HTTP請求報文由請求行（request line)、請求頭部（header)、空 行和請求數(shù)據(jù)四個部分構(gòu)成。其中，請求行中包含了請求方法（method)字段，用于表明相 應(yīng)的請求報文采用的請求方式；比如當請求報文采用GET方式時，請求行中包含"method = GET"，或者當請求報文采用POST方式時，請求行中包含"method = POST"。
[0051] 步驟410,當請求報文的請求方式為第一類型時，若代理服務(wù)器查找到該請求報文 中包含對應(yīng)于第二類型的標識參數(shù)，則轉(zhuǎn)入步驟412。
[0052] 在本實施例中，客戶端在采用GET方式來發(fā)送請求報文時，代理服務(wù)器可以全部 執(zhí)行步驟412-步驟414的處理方式；或者，由于代理服務(wù)器本身并不了解服務(wù)端對請求方 式的支持情況，因而代理服務(wù)器還可以進一步結(jié)合用戶的實際需求，判斷是否需要將請求 報文由GET方式轉(zhuǎn)換為POST方式。
[0053] 具體地，比如客戶端在生成GET方式的請求報文時，可以在請求報文中添加對應(yīng) 于POST方式的標識參數(shù)，從而表明客戶端用戶對于報文請求方式的轉(zhuǎn)換需求。舉例而言， 該標識參數(shù)可以為GET方式的請求報文的URL末端添加的諸如"_method = post"的單詞 或字符等。
[0054] 步驟412,代理服務(wù)器對請求報文進行請求參數(shù)替換處理，得到與第二類型相匹配 的修改后請求報文。
[0055] 在本實施例中，請求參數(shù)替換處理過程可以分為兩個部分：1、對于請求方法字段 的修改；2、對于content-type類型的修改。
[0056] 在修改請求方法字段時，可以將請求行中的"method = GET"修改為"method =POST" ；在修改content-type類型時，可以使得請求頭部中的content-type = app1i cat i on/x-www-form-ur1encoded 〇
[0057] 相應(yīng)地，代理服務(wù)器在將GET請求轉(zhuǎn)換為POST請求時，采用的處理邏輯可以為：
[0058]
[0059] 步驟414,代理服務(wù)器將修改后請求報文發(fā)送至服務(wù)端。
[0060] 步驟416,代理服務(wù)器接收到服務(wù)端返回的響應(yīng)報文。
[0061] 步驟418,代理服務(wù)器將響應(yīng)報文發(fā)送至客戶端。
[0062] 在本實施例中，代理服務(wù)器在接收到來自服務(wù)端的響應(yīng)報文時，假定該響應(yīng)報文 采用POST方式，則代理服務(wù)器可以直接發(fā)送至客戶端；或者，代理服務(wù)器還可以將響應(yīng)報 文的請求方法字段的內(nèi)容修改為GET，得到采用GET方式的修改后響應(yīng)報文，并將修改后響 應(yīng)報文發(fā)送至客戶端。
[0063] 此外，當采用在GET方式的請求報文中添加對應(yīng)于POST方式的標識參數(shù)的處理方 式時，代理服務(wù)器還可以向客戶端的用戶進行提示，表明自身支持對于請求報文的請求方 式的自動轉(zhuǎn)換功能；相應(yīng)地，圖5是根據(jù)本申請一示例性實施例中的另一種報文處理方法 的流程圖，可以包括以下步驟：
[0064] 步驟502,客戶端生成請求報文，該請求報文采用的請求方式為POST。
[0065] 步驟504,客戶端向服務(wù)端發(fā)送請求報文。
[0066] 步驟506,代理服務(wù)器截獲客戶端向服務(wù)端發(fā)送的請求報文。
[0067] 步驟508,代理服務(wù)器解析請求報文，查看該請求報文的請求方法字段的請求方 式。
[0068] 步驟510,當請求方式為POST時，代理服務(wù)器將請求報文直接發(fā)送至服務(wù)端。
[0069] 步驟512,代理服務(wù)器接收到服務(wù)端返回的響應(yīng)報文。
[0070] 步驟514,代理服務(wù)器將響應(yīng)報文發(fā)送至客戶端，并同時向客戶端發(fā)送提示信息。
[0071] 在本實施例中，提示信息用于指示客戶端向服務(wù)端發(fā)送請求方式為第一類型（如 GET方式）的請求報文，并在該請求報文中添加對應(yīng)于第二類型的標識參數(shù)（如"_method =post'，）。
[0072] 在本實施例中，提示信息可以在步驟514中，與響應(yīng)報文一并發(fā)送至客戶端；或 者，代理服務(wù)器也可以在其他任意時刻向客戶端發(fā)送提示信息，本申請并不對此進行限制。
[0073] 圖6示出了根據(jù)本申請的一示例性實施例的電子設(shè)備的示意結(jié)構(gòu)圖。請參考圖6， 在硬件層面，該電子設(shè)備包括處理器、內(nèi)部總線、網(wǎng)絡(luò)接口、內(nèi)存以及非易失性存儲器，當然 還可能包括其他業(yè)務(wù)所需要的硬件。處理器從非易失性存儲器中讀取對應(yīng)的計算機程序到 內(nèi)存中然后運行，在邏輯層面上形成報文處理裝置。當然，除了軟件實現(xiàn)方式之外，本申請 并不排除其他實現(xiàn)方式，比如邏輯器件抑或軟硬件結(jié)合的方式等等，也就是說以下處理流 程的執(zhí)行主體并不限定于各個邏輯單元，也可以是硬件或邏輯器件。
[0074] 請參考圖7,在軟件實施方式中，該報文處理裝置可以包括連接建立單元、報文截 獲單元、報文解析單元、替換處理單元和第一報文發(fā)送單元。其中：
[0075] 連接建立單元，分別與客戶端和服務(wù)端建立連接；
[0076] 報文截獲單元，截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所 述服務(wù)端的地址信息；
[0077] 報文解析單元，解析所述請求報文的請求行中包含的請求方法字段；
[0078] 替換處理單元，當所述請求方法字段中記錄的請求方式為第一類型時，對所述請 求報文進行請求參數(shù)替換處理，得到匹配于第二類型的修改后請求報文；
[0079] 第一報文發(fā)送單元，將所述修改后請求報文發(fā)送至所述服務(wù)端。
[0080] 可選的，還包括：
[0081] 參數(shù)判斷單元，當所述請求方法字段中記錄的請求方式為第一類型時，判斷所述 請求報文中是否包含對應(yīng)于第二類型的標識參數(shù)；
[0082] 其中，所述替換處理單元在所述請求報文中包含所述標識參數(shù)的情況下，對所述 請求報文進行請求參數(shù)替換處理。
[0083] 可選的，還包括：
[0084] 信息提示單元，當截獲所述客戶端發(fā)送的請求報文的請求方式為第二類型時，將 所述請求報文直接轉(zhuǎn)發(fā)至所述服務(wù)端，并向所述客戶端發(fā)送提示信息；
[0085] 其中，所述提示信息用于指示所述客戶端向所述服務(wù)端發(fā)送請求方式為第一類型 的請求報文，并在該請求報文中添加所述標識參數(shù)。
[0086] 可選的，所述替換處理單元具體用于：
[0087] 將所述請求報文的所述請求方法字段的內(nèi)容修改為所述第二類型；以及
[0088] 修改所述請求報文的內(nèi)容-類型content-type屬性的類型。
[0089] 可選的，所述第一類型為GET類型，所述第二類型為POST類型；以及，所述替換處 理單元具體用于：
[0090] 將所述請求報文的content-type屬性的類型修改為默認編碼類型application/ χ-www-form-urlencoded〇
[0091] 可選的，還包括：
[0092] 報文接收單元，在將所述修改后的請求報文發(fā)送至所述服務(wù)端之后，接收所述服 務(wù)端返回的響應(yīng)報文，所述響應(yīng)報文采用的請求方式為所述第二類型；
[0093] 內(nèi)容修改單元，將所述響應(yīng)報文的所述請求方法字段的內(nèi)容修改為所述第一類 型，得到匹配于所述第一類型的修改后響應(yīng)報文；
[0094] 第二報文發(fā)送單元，將所述修改后響應(yīng)報文發(fā)送至所述客戶端。
[0095] 在一個典型的配置中，計算設(shè)備包括一個或多個處理器（CPU)、輸入/輸出接口、 網(wǎng)絡(luò)接口和內(nèi)存。
[0096] 內(nèi)存可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器（RAM)和/ 或非易失性內(nèi)存等形式，如只讀存儲器（ROM)或閃存（flash RAM)。內(nèi)存是計算機可讀介質(zhì) 的示例。
[0097] 計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法 或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。 計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存（PRAM)、靜態(tài)隨機存取存儲器（SRAM)、 動態(tài)隨機存取存儲器（DRAM)、其他類型的隨機存取存儲器（RAM)、只讀存儲器（ROM)、電 可擦除可編程只讀存儲器（EEPR0M)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器 (CD-ROM)、數(shù)字多功能光盤（DVD)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁 性存儲設(shè)備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設(shè)備訪問的信息。按照本文中 的界定，計算機可讀介質(zhì)不包括暫存電腦可讀媒體（transitory media)，如調(diào)制的數(shù)據(jù)信 號和載波。
[0098] 還需要說明的是，術(shù)語"包括"、"包含"或者其任何其他變體意在涵蓋非排他性的 包含，從而使得包括一系列要素的過程、方法、商品或者設(shè)備不僅包括那些要素，而且還包 括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設(shè)備所固有的要 素。在沒有更多限制的情況下，由語句"包括一個……"限定的要素，并不排除在包括所述 要素的過程、方法、商品或者設(shè)備中還存在另外的相同要素。
[0099] 以上所述僅為本申請的較佳實施例而已，并不用以限制本申請，凡在本申請的精 神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本申請保護的范圍之內(nèi)。
【主權(quán)項】
1. 一種報文處理方法，其特征在于，包括： 分別與客戶端和服務(wù)端建立連接； 截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所述服務(wù)端的地址信 息； 解析所述請求報文的請求行中包含的請求方法字段； 當所述請求方法字段中記錄的請求方式為第一類型時，對所述請求報文進行請求參數(shù) 替換處理，得到匹配于第二類型的修改后請求報文； 將所述修改后請求報文發(fā)送至所述服務(wù)端。2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 當所述請求方法字段中記錄的請求方式為第一類型時，判斷所述請求報文中是否包含 對應(yīng)于第二類型的標識參數(shù)； 若包含，則對所述請求報文進行請求參數(shù)替換處理。3. 根據(jù)權(quán)利要求2所述的方法，其特征在于，還包括： 當截獲所述客戶端發(fā)送的請求報文的請求方式為第二類型時，將所述請求報文直接轉(zhuǎn) 發(fā)至所述服務(wù)端，并向所述客戶端發(fā)送提示信息； 其中，所述提示信息用于指示所述客戶端向所述服務(wù)端發(fā)送請求方式為第一類型的請 求報文，并在該請求報文中添加所述標識參數(shù)。4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述請求參數(shù)替換處理，包括： 將所述請求報文的所述請求方法字段的內(nèi)容修改為所述第二類型；以及 修改所述請求報文的內(nèi)容-類型content-type屬性的類型。5. 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述第一類型為GET類型，所述第二類型 為POST類型；以及，所述修改所述請求報文的content-type屬性的類型，包括： 將所述請求報文的content-type屬性的類型修改為默認編碼類型application/ χ-www-form-urlencoded。6. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 在將所述修改后的請求報文發(fā)送至所述服務(wù)端之后，接收所述服務(wù)端返回的響應(yīng)報 文，所述響應(yīng)報文采用的請求方式為所述第二類型； 將所述響應(yīng)報文的所述請求方法字段的內(nèi)容修改為所述第一類型，得到匹配于所述第 一類型的修改后響應(yīng)報文； 將所述修改后響應(yīng)報文發(fā)送至所述客戶端。7. -種報文處理裝置，其特征在于，包括： 連接建立單元，分別與客戶端和服務(wù)端建立連接； 報文截獲單元，截獲所述客戶端發(fā)送的請求報文，所述請求報文的目的地址為所述服 務(wù)端的地址信息； 報文解析單元，解析所述請求報文的請求行中包含的請求方法字段； 替換處理單元，當所述請求方法字段中記錄的請求方式為第一類型時，對所述請求報 文進行請求參數(shù)替換處理，得到匹配于第二類型的修改后請求報文； 第一報文發(fā)送單元，將所述修改后請求報文發(fā)送至所述服務(wù)端。8. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，還包括： 參數(shù)判斷單元，當所述請求方法字段中記錄的請求方式為第一類型時，判斷所述請求 報文中是否包含對應(yīng)于第二類型的標識參數(shù)； 其中，所述替換處理單元在所述請求報文中包含所述標識參數(shù)的情況下，對所述請求 報文進行請求參數(shù)替換處理。9. 根據(jù)權(quán)利要求8所述的裝置，其特征在于，還包括： 信息提示單元，當截獲所述客戶端發(fā)送的請求報文的請求方式為第二類型時，將所述 請求報文直接轉(zhuǎn)發(fā)至所述服務(wù)端，并向所述客戶端發(fā)送提示信息； 其中，所述提示信息用于指示所述客戶端向所述服務(wù)端發(fā)送請求方式為第一類型的請 求報文，并在該請求報文中添加所述標識參數(shù)。10. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述替換處理單元具體用于： 將所述請求報文的所述請求方法字段的內(nèi)容修改為所述第二類型；以及 修改所述請求報文的內(nèi)容-類型content-type屬性的類型。11. 根據(jù)權(quán)利要求10所述的裝置，其特征在于，所述第一類型為GET類型，所述第二類 型為POST類型；以及，所述替換處理單元具體用于： 將所述請求報文的content-type屬性的類型修改為默認編碼類型application/ χ-www-form-urlencoded〇12. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，還包括： 報文接收單元，在將所述修改后的請求報文發(fā)送至所述服務(wù)端之后，接收所述服務(wù)端 返回的響應(yīng)報文，所述響應(yīng)報文采用的請求方式為所述第二類型； 內(nèi)容修改單元，將所述響應(yīng)報文的所述請求方法字段的內(nèi)容修改為所述第一類型，得 到匹配于所述第一類型的修改后響應(yīng)報文； 第二報文發(fā)送單元，將所述修改后響應(yīng)報文發(fā)送至所述客戶端。
【文檔編號】H04L29/06GK105991564SQ201510061861
【公開日】2016年10月5日
【申請日】2015年2月5日
【發(fā)明人】嚴東華, 茅曉鋒, 吳日升
【申請人】阿里巴巴集團控股有限公司