超文本传输协议请求的处理方法及装置与流程

本申请涉及互联网数据处理技术领域，特别涉及超文本传输协议请求的处理方法及装置。

背景技术：

目前，用户在通过HTTP(超文本传输协议，HyperText Transfer Protocol)请求向服务器请求服务器资源时，需要将用户的请求信息携带在HTTP请求中发送给服务器。服务器可能会在某个时间段或者时间点同时接收大量的HTTP请求，那么为了防止HTTP请求量的突增导致系统的不稳定或用户体验的整体变差，可以需要将用户导向至等待页面，在用户等待一段时间后，再重新为用户提供HTTP请求的处理服务。

技术实现要素：

但是发明人发现现有技术存在以下技术问题：

在等待页面结束等待之后，客户端向用户重新提供的页面是根据从等待页面中获取到的原始参数而生成的原始页面。例如，用户已经在原始页面的输入框中输入了登录名和密码并触发了登录请求，但是一旦客户端接收到等待页面并结束等待之后，再次向用户展示的就是输入框依然空白的原始页面，用户在提交登录请求之后输入的登录名和密码信息都丢失了。这就使得用户需要重新在原始页面中输入请求信息，如果因为服务器的性能多次向客户端返回了等待页面，那么就需要用户多次输入请求信息，这无疑会增加HTTP请求处理过程中客户端与服务器的交互次数，同时也过多或者不必要地消耗了服务器的系统资源。进一步的，也给用户访问服务器带来不好的感受和体验。

本申请所要解决的技术问题是提供超文本传输协议请求的处理方法，用以尽量避免现有技术中在服务器返回等待页面的情况下需要用户 多次输入请求信息的现象，从而减少HTTP请求处理过程中客户端与服务器的交互次数，同时节约了服务器的系统资源。进一步的，还能提升用户访问服务器的感受和体验。

本申请还提供了超文本传输协议请求的处理装置，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种超文本传输协议请求的处理方法，该方法应用于服务器端，包括：

响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息；

在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息；

将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

本申请公开了一种超文本传输协议请求的处理方法，该方法应用于客户端，包括：

响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器；

接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息；

在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

本申请公开了一种超文本传输协议请求的处理装置，该装置集成于服务器上，包括：

获取模块，用于响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息；

生成模块，用于在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息；

返回等待页面模块，用于将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

本申请公开了一种超文本传输协议请求的处理装置，该装置集成于客户端上，包括：

发送模块，用于响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器；

接收等待页面模块，用于接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息；

提交模块，用于在预设的等待时间到来的情况下，重新将所述标签表单中包括的请求信息提交给服务器。

与现有技术相比，本申请包括以下优点：

在本申请实施例中，在用户提交的HTTP请求被等待处理时，无需用户再次在输入框中输入请求信息，而是由客户端根据等待页面中嵌入的form表单，重新提交包括请求信息的HTTP请求，直至服务器成功处理该HTTP请求。因此，本申请实施例可以减少客户端与服务端交互所带来的系统资源消耗，同时也避免了用户多次输入相同的请求信息，并且用户在浏览器中的URL(统一资源定位符，Uniform Resoure Locator)也是没有变化的，进一步提升了用户体验。

本申请实施例还可以避免客户端对于用户触发的HTTP请求进入无限等待的现象，从而可以释放掉客户端本次提交的HTTP请求所占用的系统资源，并且这种及时将处理结果告知用户的方式也能进一步提升用户体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述 中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的超文本传输协议请求的处理方法实施例1的流程图；

图2是本申请的HTTP请求的一种格式示意图；

图3是本申请中一种用户在地址栏发起HTTP请求的界面示意图；

图4是本申请中用户通过在输入框输入信息并点击相应的按钮来提交HTTP请求的界面示意图；

图5是本申请中一个简单的form表单的示例性示意图；

图6为本申请中一个等待页面的示例性示意图；

图7为本申请的超文本传输协议请求的处理方法实施例2的流程图；

图8为本申请的超文本传输协议请求的处理装置实施例1的结构框图；

图9为本申请的超文本传输协议请求的处理装置实施例2的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块 可以位于包括存储设备在内的本地和远程计算机存储介质中。

参考图1，示出了本申请的超文本传输协议请求的处理方法实施例1的流程图，该方法可以应用于服务器端，本实施例可以包括以下步骤：

步骤101：响应于用户通过客户端提交的HTTP请求，获取HTTP请求中携带的请求信息。

在本实施例中，用户可以通过客户端来向服务器提交HTTP请求，在该HTTP请求中携带了请求信息，例如用户希望访问的网页地址信息，或者用户输入的登录名和登录密码的信息等。其中，HTTP请求可以包括获取(GET)请求与发送(POST)请求，这两种请求都可以将请求信息通过请求参数的方式发送给服务器。但是这两种请求参数的携带方式有所不同，GET请求的方式只能将请求信息放在URL里，而POST请求则不仅可以将请求信息放在URL里，也可以通过自己的请求体来传递参数。

为了方便本领域技术人员对这两种HTTP请求有更清楚的了解，下面参考附图对其进行详细说明。参考图2所示，为HTTP请求的格式示意图。在HTTP请求中，第一行为请求行(request line)，用来表示请求类型(例如是GET请求还是POST请求等)、URL(用户请求访问的网页地址)和HTTP版本。第二行是请求头(request headers)，请求头部分的每一行都可以表示一个请求头，并且请求头以一个空行(blank line)来结束请求。在空行(blank line)后面会有请求体(request-body)，不过请求体仅存在于部分HTTP请求类型之中，例如POST请求类型。

针对GET请求来说，GET请求没有请求体，因此，请求信息是作为URL的一部分被传送到服务端。由于URL有长度限制，GET请求所能携带的请求信息的大小是有限制的，并且因为GET请求的请求信息会直接出现在地址栏中作为URL的一部分传送给服务器，所以当需要传递比较少的数据或者安全性要求不太高的请求信息可以通过GET请求传送给服务器。而POST请求会有请求体，因此请求信息可以放在请求体中被传送到服务器。PST请求可以传送较多的数据或者安全性要求比较高的数据，例如用户登陆请求，用户输入的用户名与密码就可以通过POST请求传递 到服务器。

参考图3所示，为一种HTTP请求发起的界面示意图。在图3中，用户直接在地址栏输入了目标URL进行访问，其中请求信息“q”的值是“test”，该请求信息作为URL的一部分向服务器传送。可以理解的是，如果是用户直接输入URL提交的HTTP请求，则这种请求的请求类型只能是GET请求。再参考图4所示，为用户通过在输入框输入信息并点击相应的按钮来提交HTTP请求的界面示意图。在图4中，用户点击相应的按钮之后，如果是GET请求，则请求信息可以通过URL的方式提交给服务器，而如果是POST请求，则请求信息可以包含在请求体中提交给服务器。因此，对于用户通过填写输入框控件等非输入URL的方式来提交HTTP请求时，该HTTP既可以是GET请求，也可以是POST请求。

接着返回图1，进入步骤102：在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息。

在HTTP通过客户端(例如通过客户端的浏览器)提交给服务器的情况下，服务器可以先判断该HTTP请求是否需要被等待处理。具体的，服务器可以根据系统负载，例如CPU利用率，内存利用率等参数，利用负载均衡原理来判断该HTTP请求可以被立即处理，还是需要等待一段时间之后再处理。如果该HTTP请求需要等待被处理，那么，服务器就根据HTTP请求中的请求信息来生成标签(form)表单，其中，表单项的内容包括该请求信息。

参考图5所示，图5为一个简单的form表单的示意图。form表单有两个重要属性，行为“action”表示form表单需要提交到的URL(即，用户请求访问的目标地址)，方法“method”表示提交form表单时采用的类型(例如POST或者GET)。当form表单的method为GET时，form表单的请求信息会作为URL的一部分提交给服务器，如：“/login？username＝test&password＝test”，在该URL中，请求信息中的用户名为“test”，请求信息中的密码也是“test”。而如果form表单的method为POST，则请求信息会放在POST请求的请求体中传递给服务端，例如， 某个POST请求的请求体为：username＝test&password＝test。

具体的，步骤102在实现时可以包括：

步骤A1：在所述HTTP请求需要被等待的情况下，判断所述HTTP请求的类型为获取GET请求还是发送POST请求，如果是GET请求，则进入步骤A2；如果是POST请求，则进入步骤A3。

服务器可以根据请求信息的携带方式来判断当前HTTP请求是GET请求还是POST请求。

步骤A2：生成方法为GET、行为为目标统一资源定位符URL且属性为隐藏的标签表单，并从所述目标URL中获取请求信息作为表单项；其中，所述目标URL为所述HTTP请求指向的地址。

如果是GET请求，则服务器就生成一个method为GET，action为目标URL的form表单，并将该form表单的属性设置为隐藏，同时将从目标URL中获取到的请求信息作为表单项，目标URL可以为：HTTP请求指向的、用户需要访问的目标地址。

步骤A3：生成方法为POST、行为为目标URL且属性为隐藏的标签表单，并从POST请求的请求体中获取请求信息作为表单项。

而如果是POST请求，则服务器就生成一个method为POST，action为目标URL的form表单，YE将该form表单的属性设置为隐藏，同时将从POST请求的请求体中获取到的请求信息作为表单项。

步骤103：将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

在实际应用中，因为form表单是HTML(超文本标记语言，HyperText Markup Language)页面的元素，同时本申请实施例中用户的请求信息都已经封装在form表单中，所以在本步骤中可以将包括了请求信息的form表单嵌入等待页面中，并将该等待页面返回给客户端，因为步骤102中生成的form表单的属性为隐藏，所以用户不会在客户端上呈现的等待页面中看到form表单。

可以理解的是，服务器可以设置一个等待时间，例如3秒钟，并将该 等待时间预先设置在等待页面的页面模板中。该等待时间的数值可以由本领域技术人员根据经验值或者服务器的性能等参数自主设置。那么，在服务器将等待页面返回至客户端并展示给用户之后，客户端例如展示该等待页面的浏览器就可以根据服务器预先设置好的等待时间来进行倒计时，并在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。可选的，还可以将倒计时的具体时间显示给用户。

在本实施例中，由于等待页面中嵌入的form表单的表单项包含有请求信息，并且form表单的action就是用户原始请求的目标URL，method也是用户原始请求的请求类型，所以在本步骤中客户端重新提交的请求信息与步骤101中提交的请求信息是完全一致的。可以理解的是，当包括请求信息的HTTP请求重新提交到服务器时，服务器可以接着判断该HTTP请求是否需要等待处理，即步骤101，直至该HTTP请求被服务器成功处理。参考图6所示，为实际应用中的一个等待页面的例子示意图。

可见，在本实施例中，在用户提交的HTTP请求被等待处理时，无需用户再次在输入框中输入请求信息，而是由客户端根据等待页面中嵌入的form表单，重新提交包括请求信息的HTTP请求，直至服务器成功处理该HTTP请求。因此，本申请实施例可以减少客户端与服务端交互所带来的系统资源消耗，同时也避免了用户多次输入相同的请求信息，并且用户在浏览器中的URL也是没有变化的，进一步提升了用户体验。

在实际应用中，还有一种情况，就是服务器性能在一段时间内都无法正常处理某个HTTP请求，那么服务器可能就需要向客户端返回HTTP请求处理失败的提示信息，因此，本申请实施例中的form表单还可以设置一个记录项，用来表示客户端向服务器提交同一个HTTP请求的请求信息的次数。

则在步骤103之后，该方法还可以包括：

步骤104：判断所述记录项表示的请求信息的提交次数是否大于预设的提交次数阈值，如果是，则进入步骤105。

服务器可以根据记录项来判断对于某个HTTP请求的请求信息的提 交次数是否大于预设的提交次数阈值，例如已经超过5次提交同一个HTTP请求。当然，该提交次数阈值也可以由本领域技术人员根据服务器的性能和实际需求自主设置。

步骤105：向所述客户端返回所述HTTP请求处理失败的提示信息。

如果客户端提交了5次HTTP请求都没有处理成功，那么，服务器可以不再处理该HTTP请求，并向客户端返回所述HTTP请求处理失败的提示信息。这样就可以避免客户端对于用户触发的HTTP请求进入无限等待的现象，从而释放掉客户端本次提交的HTTP请求所占用的系统资源，并且这种及时将处理结果告知用户的方式也进一步提升了用户体验。

参考图7，示出了本申请一种超文本传输协议请求的处理方法实施例2的流程图，该方法可以应用于客户端，本实施例可以包括以下步骤：

步骤701：响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器。

本实施例与实施例1的不同之处在于，本实施例是应用于客户端的，例如本实施例的执行主体可以为客户端的浏览器等能够向服务器提交HTTP请求的装置。在实际应用中，假设用户在浏览器上触发了请求信息，例如包括登录名称和登录密码的请求信息，或者直接输入了希望访问的目标URL的请求信息等，浏览器可以将包括该请求信息的HTTP请求发送给服务器。

步骤702：接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息。

服务器根据请求信息生成标签表单并返回等待页面的详细过程可以参考步骤102的论述，在此不再赘述。

步骤703：在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

客户端可以根据等待页面中设置的等待时间进行倒计时，并在预设的 等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

在实际应用中，在服务器端生成的form表单还可以设置记录项，用来表示客户端向服务器提交同一个HTTP请求的请求信息的次数，那么服务器就可以根据form表单的记录项判断某一个HTTP请求的提交次数是否大于预设的提交次数阈值，如果大于，则所述方法还可以包括：

步骤704：接收服务器返回的所述HTTP请求处理失败的提示信息以供显示；其中，所述提示信息为：服务器在判断得到所述记录项表示的请求信息的提交次数大于预设的提交次数阈值的情况下返回的。

在服务器在判断得到记录项表示的请求信息的提交次数大于预设的提交次数阈值的情况下，会向客户端返回一个HTTP请求处理失败的提示信息，客户端可以将该提示信息进行展示，以告知用户该HTTP请求的处理失败。

可见，在本实施例中，在用户提交的HTTP请求被等待处理时，无需用户再次在输入框中输入请求信息，而是由客户端根据服务器返回的等待页面中嵌入的form表单，重新提交包括请求信息的HTTP请求，直至服务器成功处理该HTTP请求。因此，本申请实施例可以减少客户端与服务端交互所带来的系统资源消耗，同时也避免了用户多次输入相同的请求信息，并且用户在浏览器中的URL也是没有变化的，进一步提升了用户体验。

进一步的，服务器还可以返回HTTP请求处理失败的提示信息，以避免客户端对于用户触发的HTTP请求进入无限等待的现象，从而释放掉客户端本次提交的HTTP请求所占用的系统资源，并且这种及时将处理结果告知用户的方式也进一步提升了用户体验。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请的超文本传输协议请求的处理方法实施例1所提供的方法相对应，参见图8，本申请还提供了一种超文本传输协议请求的处理装置实施例，在本实施例中，该装置可以集成于服务器上，该装置可以包括：

获取模块801，用于响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息。

生成模块802，用于在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息。

其中，生成模块802具体可以包括：

判断子模块，用于在所述HTTP请求需要被等待的情况下，判断所述HTTP请求的类型为获取GET请求还是发送POST请求；第一生成子模块，用于在所述HTTP请求为GET请求的情况下，生成方法为GET、行为为目标统一资源定位符URL且属性为隐藏的标签表单；第一获取子模块，用于在所述HTTP请求为GET请求HTTP请求为，从所述目标URL中获取请求信息作为表单项；其中，所述目标URL为所述HTTP请求指向的地址；第二生成子模块，用于在所述HTTP请求为POST请求的情况下，生成方法为POST、行为为目标URL且属性为隐藏的标签表单；和，第二获取子模块，用于在所述HTTP请求为POST请求的情况下，从POST请求的请求体中获取请求信息作为表单项。

返回等待页面模块803，用于将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。

在实际应用中，标签表单还设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；则所述装置还可以包括：

判断模块804，用于判断所述记录项表示的请求信息的提交次数是否大于预设的提交次数阈值；

返回提示信息模块805，用于在所述判断模块的结果为是的情况下，向所述客户端返回所述HTTP请求处理失败的提示信息。

可见，在本实施例中，在用户提交的HTTP请求被等待处理时，无需用户再次在输入框中输入请求信息，而是由客户端根据等待页面中嵌入的form表单，重新提交包括请求信息的HTTP请求，直至服务器成功处理该HTTP请求。因此，本申请实施例可以减少客户端与服务端交互所带来的系统资源消耗，同时也避免了用户多次输入相同的请求信息，并且用户在浏览器中的URL也是没有变化的，进一步提升了用户体验。

与上述本申请的超文本传输协议请求的处理方法实施例2所提供的方法相对应，参见图9，本申请还提供了一种超文本传输协议请求的处理装置实施例，在本实施例中，该装置可以集成于客户端上，该装置可以包括：

发送模块901，用于响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器。

接收等待页面模块902，用于接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息。

提交模块903，用于在预设的等待时间到来的情况下，重新将所述标签表单中包括的请求信息提交给服务器。

其中，所述标签表单还可以设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；则所述装置还可以包括：

接收提示信息模块904，用于接收服务器返回的所述HTTP请求处理失败的提示信息以供显示；其中，所述提示信息为：服务器在判断得到所述记录项表示的请求信息的提交次数大于预设的提交次数阈值的情况下返回的。

可见，在本实施例中，在用户提交的HTTP请求被等待处理时，无需 用户再次在输入框中输入请求信息，而是由客户端根据服务器返回的等待页面中嵌入的form表单，重新提交包括请求信息的HTTP请求，直至服务器成功处理该HTTP请求。因此，本申请实施例可以减少客户端与服务端交互所带来的系统资源消耗，同时也避免了用户多次输入相同的请求信息，并且用户在浏览器中的URL也是没有变化的，进一步提升了用户体验。

进一步的，服务器还可以返回HTTP请求处理失败的提示信息，以避免客户端对于用户触发的HTTP请求进入无限等待的现象，从而释放掉客户端本次提交的HTTP请求所占用的系统资源，并且这种及时将处理结果告知用户的方式也进一步提升了用户体验。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的超文本传输协议请求的处理方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方 式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。