CN105991564A - 报文处理方法及装置 - Google Patents

Abstract

本申请提供一种报文处理方法及装置，该方法包括：分别与客户端和服务端建立连接；截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；解析所述请求报文的请求行中包含的请求方法字段；当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；将所述修改后请求报文发送至所述服务端。通过本申请的技术方案，可以使用户采用自己更加习惯、效率更高的报文类型，并基于对报文类型的自动转换，确保服务端的正确响应。

Description

报文处理方法及装置

技术领域

本申请涉及报文传输技术领域，尤其涉及报文处理方法及装置。

背景技术

在客户端与服务端之间的交互过程中，客户端通过向服务端发送请求报文，实现客户端对服务端的数据传达，或者客户端还可以从服务端获取对应的响应数据。

然而，在既定的应用场景中，服务端对来自客户端的请求报文存在一定的要求，即该请求报文应当采用某个或某些固定类型的请求方式，否则将无法正确识别和响应该请求报文。

发明内容

有鉴于此，本申请提供一种报文处理方法及装置，可以解决相关技术中的不足。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种报文处理方法，包括：

分别与客户端和服务端建立连接；

截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；

解析所述请求报文的请求行中包含的请求方法字段；

当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；

将所述修改后请求报文发送至所述服务端。

根据本申请的第二方面，提出了一种报文处理装置，包括：

连接建立单元，分别与客户端和服务端建立连接；

报文截获单元，截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；

报文解析单元，解析所述请求报文的请求行中包含的请求方法字段；

替换处理单元，当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；

第一报文发送单元，将所述修改后请求报文发送至所述服务端。

由以上技术方案可见，本申请通过对请求报文执行自动化的请求参数替换处理，使得无论服务端对请求报文的请求方式(或报文类型)存在任何要求，用户均可以采用自己习惯采用、效率更高的请求方式来生成请求报文，并通过上述的请求参数替换处理来实现请求方式的自动转换，从而满足服务端的上述要求，确保服务端能够实现正确响应。

附图说明

图1是相关技术中的报文传输的应用场景示意图；

图2是根据本申请一示例性实施例中的一种报文处理方法的流程图；

图3是根据本申请一示例性实施例中的报文传输的应用场景示意图；

图4是根据本申请一示例性实施例中的另一种报文处理方法的流程图；

图5是根据本申请一示例性实施例中的又一种报文处理方法的流程图；

图6是根据本申请一示例性实施例中的一种电子设备的结构示意图；

图7是根据本申请一示例性实施例中的一种报文处理装置的框图。

具体实施方式

图1是相关技术中的报文传输的应用场景示意图，如图1所示，在相关技术中的报文传输是在客户端与服务端之间直接完成；或者，在客户端与服务端之间可能配置有代理服务器，但代理服务器并不对客户端和服务端发送的报文进行修改，相当于在客户端与服务端之间直接实现报文传输。

在既定的应用场景下，服务端只能够对某个或某些固定类型的请求方式进行正确响应。举例而言，假定服务端仅能够对POST方式的请求报文进行正确响应，而当客户端发出其他请求方式的请求报文时，比如GET方式的请求报文，则将导致服务端无法正确地对请求报文进行识别和响应。

然而，以POST方式与GET方式为例，当请求报文采用GET方式时，只需要将待传输参数输入URL并进行访问即可，操作简单、高效；而当请求报文采用POST方式时，则需要涉及到代码修改、页面表单渲染等处理，过程繁琐、耗时。

因此，本申请通过提出一种报文处理方法及装置，可以同时满足客户端的简单、高效操作，以及服务端对请求报文的正确解析与响应。为对本申请进行进一步说明，提供下列实施例：

图2是根据本申请一示例性实施例中的一种报文处理方法的流程图，如图2所示，该方法应用于代理服务器，可以包括以下步骤：

步骤202，分别与客户端和服务端建立连接。

步骤204，截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息。

步骤206，解析所述请求报文的请求行中包含的请求方法字段。

在本实施例中，当所述请求方法字段中记录的请求方式为第一类型时，可以判断所述请求报文中是否包含对应于第二类型的标识参数，若包含，则对所述请求报文进行请求参数替换处理。那么，通过在第一类型的请求报文中添加对应于第二类型的标识参数，使得代理服务器可以准确判定客户端存在对该请求报文进行类型转换的需求。

步骤208，当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文。

在本实施例中，在执行请求参数替换处理时，可以包括：将所述请求报文的所述请求方法字段的内容修改为所述第二类型；以及，修改所述请求报文的content-type类型。其中，当第一类型为GET类型、第二类型为POST类型时，修改后请求报文的内容-类型content-type属性的类型为默认编码类型application/x-www-form-urlencoded，以使得窗体数据被编码为名称/值对。

在本实施例中，当截获的请求报文采用了第二类型时，说明客户端可能并不了解代理服务器提供的“请求参数替换处理”的功能，可以将请求报文直接转发至服务端，并向客户端发送提示信息，该提示信息用于指示所述客户端向所述服务端发送请求方式为第一类型的请求报文，并在该请求报文中添加所述标识参数。

步骤210，将所述修改后请求报文发送至所述服务端。

在本实施例中，在将所述修改后的请求报文发送至所述服务端之后，若接收所述服务端返回的响应报文，且所述响应报文采用的请求方式为所述第二类型，则还可以将所述响应报文的所述请求方法字段的内容修改为所述第一类型，得到匹配于所述第一类型的修改后响应报文；然后，将所述修改后响应报文发送至所述客户端。

由上述实施例可知，本申请通过对请求报文执行自动化的请求参数替换处理，使得无论服务端对请求报文的请求方式(或报文类型)存在任何要求，用户均可以采用自己习惯采用、效率更高的请求方式来生成请求报文，并通过上述的请求参数替换处理来实现请求方式的自动转换，从而满足服务端的上述要求，确保服务端能够实现正确响应。

图3是根据本申请一示例性实施例中的报文传输的应用场景示意图，如图3所述，在本申请的技术方案的应用场景中，包含客户端、代理服务器和服务端；其中，客户端生成并发送请求报文，而代理服务器通过对该请求报文的截获和修改后，将修改后请求报文发送至服务端，实现客户端与服务端之间的报文传输和响应。具体地，图4是根据本申请一示例性实施例中的另一种报文处理方法的流程图，该方法可以包括以下步骤：

步骤402，客户端生成请求报文，该请求报文采用的请求方式为第一类型。

在本实施例中，作为一示例性实施例，假定第一类型为GET方式，而第二类型为POST方式。GET方式和POST方式均属于HTTP(用于举例，也可以为HTTPS)报文的不同方式；其中，GET方式直接通过URL(UniformResoure Locator，统一资源定位器)发送请求报文并提交数据，且数据直接可见于该URL中；而POST方式则基于表单形式，具体将数据包含在HTTP请求头部(header)内。

可见，相比于POST方式，通过GET方式生成请求报文(即HTTP请求报文)的过程显然更为简单、快捷。然而，在一些应用场景中，服务端仅识别POST方式的请求报文，而无法对GET方式的请求报文做出正确响应。

因此，在本实施例中，基于本申请提出的技术方案，客户端可以采用更为简单高效的GET方式生成请求报文，并通过后续步骤确保服务端的正确响应，有助于简化技术方案的实现流程、提升请求效率。

步骤404，客户端向服务端发送请求报文。

步骤406，代理服务器截获客户端向服务端发送的请求报文。

在本实施例中，通过对代理服务器的配置，可以对客户端与服务端之间的传输报文进行监控，比如当接收到的报文的源地址为客户端的地址信息、目的地址为服务端的地址信息时，就截获该报文并避免该报文的直接发送。

步骤408，代理服务器解析请求报文，查看该请求报文的请求方法字段的请求方式。

在本实施例中，HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据四个部分构成。其中，请求行中包含了请求方法(method)字段，用于表明相应的请求报文采用的请求方式；比如当请求报文采用GET方式时，请求行中包含“method＝GET”，或者当请求报文采用POST方式时，请求行中包含“method＝POST”。

步骤410，当请求报文的请求方式为第一类型时，若代理服务器查找到该请求报文中包含对应于第二类型的标识参数，则转入步骤412。

在本实施例中，客户端在采用GET方式来发送请求报文时，代理服务器可以全部执行步骤412-步骤414的处理方式；或者，由于代理服务器本身并不了解服务端对请求方式的支持情况，因而代理服务器还可以进一步结合用户的实际需求，判断是否需要将请求报文由GET方式转换为POST方式。

具体地，比如客户端在生成GET方式的请求报文时，可以在请求报文中添加对应于POST方式的标识参数，从而表明客户端用户对于报文请求方式的转换需求。举例而言，该标识参数可以为GET方式的请求报文的URL末端添加的诸如“__method＝post”的单词或字符等。

步骤412，代理服务器对请求报文进行请求参数替换处理，得到与第二类型相匹配的修改后请求报文。

在本实施例中，请求参数替换处理过程可以分为两个部分：1、对于请求方法字段的修改；2、对于content-type类型的修改。

在修改请求方法字段时，可以将请求行中的“method＝GET”修改为“method＝POST”；在修改content-type类型时，可以使得请求头部中的content-type＝application/x-www-form-urlencoded。

相应地，代理服务器在将GET请求转换为POST请求时，采用的处理逻辑可以为：

步骤414，代理服务器将修改后请求报文发送至服务端。

步骤416，代理服务器接收到服务端返回的响应报文。

步骤418，代理服务器将响应报文发送至客户端。

在本实施例中，代理服务器在接收到来自服务端的响应报文时，假定该响应报文采用POST方式，则代理服务器可以直接发送至客户端；或者，代理服务器还可以将响应报文的请求方法字段的内容修改为GET，得到采用GET方式的修改后响应报文，并将修改后响应报文发送至客户端。

此外，当采用在GET方式的请求报文中添加对应于POST方式的标识参数的处理方式时，代理服务器还可以向客户端的用户进行提示，表明自身支持对于请求报文的请求方式的自动转换功能；相应地，图5是根据本申请一示例性实施例中的另一种报文处理方法的流程图，可以包括以下步骤：

步骤502，客户端生成请求报文，该请求报文采用的请求方式为POST。

步骤504，客户端向服务端发送请求报文。

步骤506，代理服务器截获客户端向服务端发送的请求报文。

步骤508，代理服务器解析请求报文，查看该请求报文的请求方法字段的请求方式。

步骤510，当请求方式为POST时，代理服务器将请求报文直接发送至服务端。

步骤512，代理服务器接收到服务端返回的响应报文。

步骤514，代理服务器将响应报文发送至客户端，并同时向客户端发送提示信息。

在本实施例中，提示信息用于指示客户端向服务端发送请求方式为第一类型(如GET方式)的请求报文，并在该请求报文中添加对应于第二类型的标识参数(如“__method＝post”)。

在本实施例中，提示信息可以在步骤514中，与响应报文一并发送至客户端；或者，代理服务器也可以在其他任意时刻向客户端发送提示信息，本申请并不对此进行限制。

图6示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图6，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成报文处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图7，在软件实施方式中，该报文处理装置可以包括连接建立单元、报文截获单元、报文解析单元、替换处理单元和第一报文发送单元。其中：

连接建立单元，分别与客户端和服务端建立连接；

报文截获单元，截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；

报文解析单元，解析所述请求报文的请求行中包含的请求方法字段；

替换处理单元，当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；

第一报文发送单元，将所述修改后请求报文发送至所述服务端。

可选的，还包括：

参数判断单元，当所述请求方法字段中记录的请求方式为第一类型时，判断所述请求报文中是否包含对应于第二类型的标识参数；

其中，所述替换处理单元在所述请求报文中包含所述标识参数的情况下，对所述请求报文进行请求参数替换处理。

可选的，还包括：

信息提示单元，当截获所述客户端发送的请求报文的请求方式为第二类型时，将所述请求报文直接转发至所述服务端，并向所述客户端发送提示信息；

其中，所述提示信息用于指示所述客户端向所述服务端发送请求方式为第一类型的请求报文，并在该请求报文中添加所述标识参数。

可选的，所述替换处理单元具体用于：

将所述请求报文的所述请求方法字段的内容修改为所述第二类型；以及

修改所述请求报文的内容-类型content-type属性的类型。

可选的，所述第一类型为GET类型，所述第二类型为POST类型；以及，所述替换处理单元具体用于：

将所述请求报文的content-type属性的类型修改为默认编码类型application/x-www-form-urlencoded。

可选的，还包括：

报文接收单元，在将所述修改后的请求报文发送至所述服务端之后，接收所述服务端返回的响应报文，所述响应报文采用的请求方式为所述第二类型；

内容修改单元，将所述响应报文的所述请求方法字段的内容修改为所述第一类型，得到匹配于所述第一类型的修改后响应报文；

第二报文发送单元，将所述修改后响应报文发送至所述客户端。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (12)

1.一种报文处理方法，其特征在于，包括：

分别与客户端和服务端建立连接；

截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；

解析所述请求报文的请求行中包含的请求方法字段；

当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；

将所述修改后请求报文发送至所述服务端。

2.根据权利要求1所述的方法，其特征在于，还包括：

当所述请求方法字段中记录的请求方式为第一类型时，判断所述请求报文中是否包含对应于第二类型的标识参数；

若包含，则对所述请求报文进行请求参数替换处理。

3.根据权利要求2所述的方法，其特征在于，还包括：

当截获所述客户端发送的请求报文的请求方式为第二类型时，将所述请求报文直接转发至所述服务端，并向所述客户端发送提示信息；

其中，所述提示信息用于指示所述客户端向所述服务端发送请求方式为第一类型的请求报文，并在该请求报文中添加所述标识参数。

4.根据权利要求1所述的方法，其特征在于，所述请求参数替换处理，包括：

将所述请求报文的所述请求方法字段的内容修改为所述第二类型；以及

修改所述请求报文的内容-类型content-type属性的类型。

5.根据权利要求4所述的方法，其特征在于，所述第一类型为GET类型，所述第二类型为POST类型；以及，所述修改所述请求报文的content-type属性的类型，包括：

将所述请求报文的content-type属性的类型修改为默认编码类型application/x-www-form-urlencoded。

6.根据权利要求1所述的方法，其特征在于，还包括：

在将所述修改后的请求报文发送至所述服务端之后，接收所述服务端返回的响应报文，所述响应报文采用的请求方式为所述第二类型；

将所述响应报文的所述请求方法字段的内容修改为所述第一类型，得到匹配于所述第一类型的修改后响应报文；

将所述修改后响应报文发送至所述客户端。

7.一种报文处理装置，其特征在于，包括：

连接建立单元，分别与客户端和服务端建立连接；

报文截获单元，截获所述客户端发送的请求报文，所述请求报文的目的地址为所述服务端的地址信息；

报文解析单元，解析所述请求报文的请求行中包含的请求方法字段；

替换处理单元，当所述请求方法字段中记录的请求方式为第一类型时，对所述请求报文进行请求参数替换处理，得到匹配于第二类型的修改后请求报文；

第一报文发送单元，将所述修改后请求报文发送至所述服务端。

8.根据权利要求7所述的装置，其特征在于，还包括：

参数判断单元，当所述请求方法字段中记录的请求方式为第一类型时，判断所述请求报文中是否包含对应于第二类型的标识参数；

其中，所述替换处理单元在所述请求报文中包含所述标识参数的情况下，对所述请求报文进行请求参数替换处理。

9.根据权利要求8所述的装置，其特征在于，还包括：

信息提示单元，当截获所述客户端发送的请求报文的请求方式为第二类型时，将所述请求报文直接转发至所述服务端，并向所述客户端发送提示信息；

其中，所述提示信息用于指示所述客户端向所述服务端发送请求方式为第一类型的请求报文，并在该请求报文中添加所述标识参数。

10.根据权利要求7所述的装置，其特征在于，所述替换处理单元具体用于：

将所述请求报文的所述请求方法字段的内容修改为所述第二类型；以及

修改所述请求报文的内容-类型content-type属性的类型。

11.根据权利要求10所述的装置，其特征在于，所述第一类型为GET类型，所述第二类型为POST类型；以及，所述替换处理单元具体用于：

将所述请求报文的content-type属性的类型修改为默认编码类型application/x-www-form-urlencoded。

12.根据权利要求7所述的装置，其特征在于，还包括：

报文接收单元，在将所述修改后的请求报文发送至所述服务端之后，接收所述服务端返回的响应报文，所述响应报文采用的请求方式为所述第二类型；

内容修改单元，将所述响应报文的所述请求方法字段的内容修改为所述第一类型，得到匹配于所述第一类型的修改后响应报文；

第二报文发送单元，将所述修改后响应报文发送至所述客户端。