WO2016155491A1 - 超文本传输协议请求的处理方法及装置 - Google Patents

超文本传输协议请求的处理方法及装置 Download PDF

Info

Publication number
WO2016155491A1
WO2016155491A1 PCT/CN2016/076409 CN2016076409W WO2016155491A1 WO 2016155491 A1 WO2016155491 A1 WO 2016155491A1 CN 2016076409 W CN2016076409 W CN 2016076409W WO 2016155491 A1 WO2016155491 A1 WO 2016155491A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
server
request information
http request
http
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2016/076409
Other languages
English (en)
French (fr)
Inventor
李飞勃
蔡景现
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2016155491A1 publication Critical patent/WO2016155491A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • the present application relates to the field of Internet data processing technologies, and in particular, to a method and an apparatus for processing a hypertext transfer protocol request.
  • HTTP HyperText Transfer Protocol
  • the server may receive a large number of HTTP requests at the same time or at the same time.
  • the user may need to be directed to the waiting page. After the user waits for a period of time, the user is again provided with a processing service for the HTTP request.
  • the page that the client re-provisions to the user is the original page generated from the original parameters obtained from the waiting page. For example, the user has entered the login name and password in the input box of the original page and triggered the login request, but once the client receives the waiting page and ends the waiting, the user is again presented with the original page where the input box is still blank, the user The login name and password information entered after submitting the login request are lost. This makes the user need to re-enter the request information in the original page. If the waiting page is returned to the client multiple times because of the performance of the server, the user needs to input the request information multiple times, which will undoubtedly increase the client during the HTTP request processing. The number of interactions with the server, too, or excessively or unnecessarily consumes the server's system resources. Further, it also brings bad feelings and experiences to the user accessing the server.
  • the technical problem to be solved by the present application is to provide a processor for requesting a hypertext transfer protocol.
  • the method is used to avoid the phenomenon that the user needs to input the request information multiple times in the case that the server returns the waiting page in the prior art, thereby reducing the number of interactions between the client and the server during the HTTP request processing, and saving the system resources of the server. . Further, it can also enhance the user experience and experience of accessing the server.
  • the present application also provides a processing device for a hypertext transfer protocol request to ensure the implementation and application of the above method in practice.
  • the present application discloses a processing method for a hypertext transfer protocol request, which is applied to a server, and includes:
  • the waiting page embedded with the tag form is returned to the client, so that the client re-submits the request information included in the tag form to the server when the preset waiting time comes.
  • the present application discloses a processing method for a hypertext transfer protocol request, which is applied to a client, and includes:
  • the label form is: a label form generated by the server according to the request information in the case that the HTTP request needs to be waited, the label
  • the form item of the form includes the request information
  • the request information included in the label form is resubmitted to the server.
  • the present application discloses a processing device for a hypertext transfer protocol request, which is integrated on a server, and includes:
  • An obtaining module configured to obtain request information carried in an HTTP request, in response to a hypertext transfer protocol HTTP request submitted by the user through the client;
  • the waiting page module for returning the waiting page embedded with the label form to the client, so that the client re-submits the request information included in the label form when the preset waiting time arrives Give the server.
  • the present application discloses a processing device for a hypertext transfer protocol request, which is integrated on a client, and includes:
  • a sending module configured to send a hypertext transfer protocol HTTP request including the request information to a server, in response to the request information triggered by the user;
  • Receiving a waiting page module configured to receive a waiting page that is returned by the server and embedded with a label form for display; wherein the label form is: in case the HTTP request needs to be waited, the server generates according to the request information a form of the form, the form item of the form includes the request information;
  • the submitting module is configured to re-submit the request information included in the label form to the server in a case where the preset waiting time comes.
  • the present application includes the following advantages:
  • the embodiment of the present application when the HTTP request submitted by the user is waiting for processing, the user does not need to input the request information in the input box again, but the client re-submits the HTTP including the request information according to the form form embedded in the waiting page. Request until the server successfully processes the HTTP request. Therefore, the embodiment of the present application can reduce the system resource consumption caused by the interaction between the client and the server, and also avoid the user inputting the same request information multiple times, and the URL of the user in the browser (uniform resource locator, Uniform) Resoure Locator) has not changed, further enhancing the user experience.
  • Uniform resource locator Uniform resource locator
  • the embodiment of the present application can also prevent the client from entering the infinite waiting for the HTTP request triggered by the user, so that the system resources occupied by the HTTP request submitted by the client this time can be released, and the manner of notifying the user of the processing result in time is provided. It can further enhance the user experience.
  • Embodiment 1 is a flowchart of Embodiment 1 of a processing method of a Hypertext Transfer Protocol request of the present application
  • FIG. 2 is a schematic diagram of a format of an HTTP request of the present application
  • FIG. 3 is a schematic diagram of an interface for a user to initiate an HTTP request in an address bar in the present application
  • FIG. 4 is a schematic diagram of an interface for a user to submit an HTTP request by inputting information in an input box and clicking a corresponding button in the present application;
  • Figure 5 is an exemplary schematic diagram of a simple form form in the present application.
  • FIG. 6 is an exemplary schematic diagram of a waiting page in the present application.
  • Embodiment 7 is a flowchart of Embodiment 2 of a method for processing a Hypertext Transfer Protocol request according to the present application
  • Embodiment 8 is a structural block diagram of Embodiment 1 of a processing apparatus for a Hypertext Transfer Protocol request according to the present application;
  • FIG. 9 is a structural block diagram of Embodiment 2 of a processing apparatus for a Hypertext Transfer Protocol request according to the present application.
  • This application can be used in a variety of general purpose or special purpose computing device environments or configurations.
  • personal computer server computer, handheld or portable device, tablet type device, multi-processor device, distributed computing environment including any of the above devices or devices, and the like.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • the present application can also be practiced in a distributed computing environment, in a distributed computing environment The connected remote processing device performs the task.
  • program modules can be located in both local and remote computer storage media including storage devices.
  • Embodiment 1 of a method for processing a Hypertext Transfer Protocol request of the present application is shown.
  • the method may be applied to a server.
  • the embodiment may include the following steps:
  • Step 101 Acquire the request information carried in the HTTP request in response to the HTTP request submitted by the user through the client.
  • the user may submit an HTTP request to the server through the client, where the HTTP request carries the request information, such as the webpage address information that the user wants to access, or the login name and the login password information input by the user.
  • the HTTP request may include a Get (GET) Request and Send (POST) request, and both of the requests may send the request information to the server by using a request parameter.
  • the two request parameters are carried differently.
  • the GET request can only place the request information in the URL, and the POST request can not only put the request information in the URL, but also pass the request body. parameter.
  • FIG. 2 it is a schematic diagram of the format of an HTTP request.
  • the first line is a request line that indicates the type of request (for example, a GET request or a POST request), a URL (a web address requested by the user), and an HTTP version.
  • the second line is the request headers.
  • Each line of the request header can represent a request header, and the request header ends the request with a blank line.
  • the GET request has no request body, so the request information is transmitted to the server as part of the URL. Since the URL has a length limit, the size of the request information that the GET request can carry is limited, and since the request information of the GET request is directly transmitted to the server as part of the URL in the address bar, when there is less need to be transmitted, Request information with less data or security requirements can be transmitted to the server via a GET request.
  • the POST request will have a request body, so the request information can be transferred to the server in the request body.
  • PST requests can transmit more data or data with higher security requirements. For example, a user login request, the user name and password entered by the user can be delivered to the server through a POST request.
  • FIG. 3 a schematic diagram of an interface initiated by an HTTP request.
  • the user directly enters the target URL in the address bar for access, wherein the value of the request information "q" is "test”, and the request information is transmitted to the server as part of the URL.
  • the request type of the request can only be a GET request.
  • FIG. 4 an interface diagram for the user to submit an HTTP request by inputting information in the input box and clicking the corresponding button.
  • the request information can be submitted to the server by means of a URL, and if it is a POST request, the request information can be included in the request body and submitted to the server. Therefore, when a user submits an HTTP request by filling in a non-input URL such as an input box control, the HTTP can be either a GET request or a POST request.
  • step 102 in the case that the HTTP request needs to be waited, generating a label form according to the request information; wherein the form item of the label form includes the request information.
  • the server can first determine whether the HTTP request needs to be processed. Specifically, the server may use the load balancing principle to determine whether the HTTP request can be processed immediately according to system load, such as CPU utilization, memory utilization, and the like, or wait for a period of time before processing. If the HTTP request needs to wait for processing, the server generates a form based on the request information in the HTTP request, wherein the content of the form item includes the request information.
  • FIG. 5 is a schematic diagram of a simple form form.
  • the form form has two important properties.
  • the action "action” indicates the URL to which the form form needs to be submitted (that is, the target address that the user requests to access), and the method “method” indicates the type (such as POST or GET) used when submitting the form.
  • the form of the form form is GET
  • the form form method For POST the request information is passed to the server in the request body of the POST request.
  • step 102 may include:
  • Step A1 In the case that the HTTP request needs to be waited, determine whether the type of the HTTP request is to obtain a GET request or a POST request, if it is a GET request, go to step A2; if it is a POST request, go to step A3. .
  • the server can determine whether the current HTTP request is a GET request or a POST request according to the manner in which the request information is carried.
  • Step A2 The generating method is GET, the behavior is the target uniform resource locator URL and the attribute is a hidden label form, and the request information is obtained from the target URL as a form item; wherein the target URL is the HTTP request pointing the address of.
  • the server If it is a GET request, the server generates a form with a method of GET, the action is the target URL, and sets the property of the form to be hidden, and the request information obtained from the target URL is used as a form item, the target URL.
  • Step A3 The generation method is a POST, the behavior is a target URL, and the attribute is a hidden label form, and the request information is obtained as a form item from the request body of the POST request.
  • the server If it is a POST request, the server generates a form that is a POST, and the action is a form of the target URL.
  • the YE sets the attribute of the form to be hidden, and the request information obtained from the request body of the POST request is used as a table. Single item.
  • Step 103 Return a waiting page embedded with the label form to the client, so that the client re-submits the request information included in the label form to the server when a preset waiting time arrives.
  • the form is an element of an HTML (HyperText Markup Language) page
  • the request information of the user in the embodiment of the present application is already encapsulated in the form, it may be included in this step.
  • the form form of the request information is embedded in the waiting page, and the waiting page is returned to the client, because the attribute of the form form generated in step 102 is hidden, so the user does not see the form in the waiting page presented on the client.
  • HTML HyperText Markup Language
  • the server can set a waiting time, for example, 3 seconds, and preset the waiting time in the page template of the waiting page.
  • the value of the waiting time can be set autonomously by a person skilled in the art based on parameters such as empirical values or performance of the server.
  • the client for example, the browser displaying the waiting page can count down according to the preset waiting time of the server, and when the preset waiting time comes Resubmitting the request information included in the tag form to the server.
  • the specific time of the countdown can also be displayed to the user.
  • the method is also the request type of the original request of the user, so the client in this step
  • the request information resubmitted is exactly the same as the request information submitted in step 101. It can be understood that when an HTTP request including request information is resubmitted to the server, the server can then determine whether the HTTP request needs to wait for processing, step 101, until the HTTP request is successfully processed by the server. Referring to FIG. 6, a schematic diagram of an example of a waiting page in an actual application.
  • the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving.
  • the user experience when the HTTP request submitted by the user is waiting for processing, the user does not need to input the request information in the input box again, but the client resubmits the request information according to the form form embedded in the waiting page. HTTP request until the server successfully processes the HTTP request. Therefore, the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving. The user experience.
  • the form form can also set a record item to indicate the number of times the client submits the request information for the same HTTP request to the server.
  • the method may further include:
  • Step 104 Determine whether the number of submissions of the request information indicated by the record item is greater than a preset number of submission times threshold, and if yes, proceed to step 105.
  • the server may determine, according to the record item, whether the number of times the request information of the HTTP request is submitted is greater than a preset number of submission times, for example, the same HTTP request has been submitted more than 5 times.
  • a preset number of submission times for example, the same HTTP request has been submitted more than 5 times.
  • the threshold of the number of submissions can also be set autonomously by those skilled in the art according to the performance and actual needs of the server.
  • Step 105 Return, to the client, the prompt information that the HTTP request processing fails.
  • the server may no longer process the HTTP request, and return the prompt message that the HTTP request processing fails to the client. In this way, the client can prevent the HTTP request initiated by the user from entering the infinite waiting state, thereby releasing the system resources occupied by the HTTP request submitted by the client, and the manner of notifying the user of the processing result in time is further improved. user experience.
  • Embodiment 2 of a method for processing a Hypertext Transfer Protocol request of the present application is shown.
  • the method may be applied to a client.
  • the embodiment may include the following steps:
  • Step 701 Send a Hypertext Transfer Protocol (HTTP) request including the request information to the server in response to the request information triggered by the user.
  • HTTP Hypertext Transfer Protocol
  • the embodiment is applied to the client.
  • the execution entity of the embodiment may be a device such as a browser of the client that can submit an HTTP request to the server.
  • the user triggers the request information on the browser, for example, the request information including the login name and the login password, or directly inputs the request information of the target URL that the user wants to access, etc., and the browser may include the request information.
  • An HTTP request is sent to the server.
  • Step 702 The waiting page that is returned by the server and embedded with the label form is displayed for display.
  • the label form is: a label form generated by the server according to the request information if the HTTP request needs to be waited.
  • the form item of the label form includes the request information.
  • step 102 For a detailed process of generating a label form and returning a waiting page according to the request information, refer to the discussion of step 102, and details are not described herein again.
  • Step 703 Submit the request information included in the label form to the server again when the preset waiting time comes.
  • the client can count down according to the waiting time set in the waiting page, and resubmit the request information included in the label form to the server when the preset waiting time comes.
  • the form form generated on the server side can also set a record item, which is used to indicate the number of times the client submits the request information of the same HTTP request to the server, and the server can determine an HTTP according to the record item of the form form. Whether the requested number of submissions is greater than a preset number of submission thresholds, and if the method is greater than, the method may further include:
  • Step 704 Receive prompt information of the HTTP request processing failure returned by the server for display; wherein the prompt information is: the server determines that the number of submissions of the request information indicated by the record item is greater than a preset number of submission times threshold The case is returned.
  • the server determines that the number of submissions of the request information indicated by the record item is greater than the preset number of submission times, the server returns a prompt message that the HTTP request processing fails, and the client may display the prompt information to Tell the user that the processing of the HTTP request failed.
  • the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving.
  • the user experience when the HTTP request submitted by the user is waiting for processing, the user does not need to input the request information in the input box again, but the client re-submits the form according to the form form embedded in the waiting page returned by the server. Request an HTTP request for the message until the server successfully processes the HTTP request. Therefore, the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving. The user experience.
  • the server may also return a prompt message that the HTTP request processing fails, so as to prevent the client from entering the infinite waiting for the HTTP request triggered by the user, thereby releasing the system resources occupied by the HTTP request submitted by the client this time, and this The way to inform the user of the processing results in a timely manner further enhances the user experience.
  • the present application further provides an embodiment of a processing device for a hypertext transfer protocol request, in this embodiment.
  • the device can be integrated on a server, and the device can include:
  • the obtaining module 801 is configured to obtain the request information carried in the HTTP request in response to the hypertext transfer protocol HTTP request submitted by the user through the client.
  • the generating module 802 is configured to generate a label form according to the request information if the HTTP request needs to be waited; wherein the form item of the label form includes the request information.
  • the generating module 802 may specifically include:
  • a determining submodule configured to determine, according to the HTTP request that the HTTP request needs to be waited, whether the type of the HTTP request is a GET request or a POST request; and the first generating submodule is configured to perform a GET request on the HTTP request
  • the generation method is GET
  • the behavior is the target uniform resource locator URL and the attribute is a hidden label form
  • the first acquisition sub-module is configured to: in the HTTP request, the GET request HTTP request is from the target URL Obtaining the request information as a form item; wherein the target URL is an address pointed by the HTTP request
  • the second generating submodule is configured to: when the HTTP request is a POST request, the generating method is POST, and the behavior is a target URL and the attribute is a hidden label form
  • a second obtaining sub-module for obtaining the request information as a form item from the request body of the POST request if the HTTP request is a POST request.
  • waiting page module 803 configured to return a waiting page embedded with the label form to the client, so that the client re-requests the request information included in the label form when a preset waiting time arrives Submit to the server.
  • the label form is further provided with a record item, where the record item is used to indicate the number of times the client submits the request information of the same HTTP request to the server;
  • the device may further include:
  • the determining module 804 is configured to determine whether the number of submissions of the request information indicated by the record item is Greater than the preset number of submission thresholds;
  • the return prompt information module 805 is configured to, when the result of the determining module is YES, return the prompt information of the HTTP request processing failure to the client.
  • the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving.
  • the user experience when the HTTP request submitted by the user is waiting for processing, the user does not need to input the request information in the input box again, but the client resubmits the request information according to the form form embedded in the waiting page. HTTP request until the server successfully processes the HTTP request. Therefore, the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving. The user experience.
  • the present application further provides an embodiment of a processing device for a hypertext transfer protocol request, in this embodiment.
  • the device can be integrated on the client, and the device can include:
  • the sending module 901 is configured to send a hypertext transfer protocol HTTP request including the request information to the server in response to the request information triggered by the user.
  • the receiving waiting page module 902 is configured to receive a waiting page that is returned by the server and embedded with the label form for display; wherein the label form is: in case the HTTP request needs to be waited, the server according to the request information A generated tag form, the form item of the tag form including the request information.
  • the submitting module 903 is configured to re-submit the request information included in the label form to the server when the preset waiting time comes.
  • the tag form may further be configured with a record item, where the record item is used to indicate the number of times the client submits the request information of the same HTTP request to the server; the device may further include:
  • the receiving prompt information module 904 is configured to receive the prompt information of the HTTP request processing failure returned by the server for display; wherein the prompt information is: the server determines that the number of submissions of the request information indicated by the record item is greater than a pre- Returns if the number of submission thresholds is set.
  • the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving.
  • the user experience when the HTTP request submitted by the user is waiting for processing, the user does not need to input the request information in the input box again, but the client re-submits the form according to the form form embedded in the waiting page returned by the server. Request an HTTP request for the message until the server successfully processes the HTTP request. Therefore, the embodiment of the present application can reduce system resource consumption caused by interaction between the client and the server, and also avoids the user inputting the same request information multiple times, and the URL of the user in the browser is unchanged, further improving. The user experience.
  • the server may also return a prompt message that the HTTP request processing fails, so as to prevent the client from entering the infinite waiting for the HTTP request triggered by the user, thereby releasing the system resources occupied by the HTTP request submitted by the client this time, and this The way to inform the user of the processing results in a timely manner further enhances the user experience.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了超文本传输协议请求的处理方法及装置，其中一种方法该方法应用于服务器端，包括：响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息；在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息；将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。在本申请实施例中，可以减少客户端与服务器的交互次数，从而节约服务器的资源，还能提升用户体验。

Description

超文本传输协议请求的处理方法及装置 技术领域
本申请涉及互联网数据处理技术领域，特别涉及超文本传输协议请求的处理方法及装置。
背景技术
目前，用户在通过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请求所占用的系统资源，并且这种及时将处理结果告知用户的方式也进一步提升了用户体验。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本申请所提供的超文本传输协议请求的处理方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想； 同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

  1. 一种超文本传输协议请求的处理方法，其特征在于，该方法应用于服务器端，包括：
    响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息；
    在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息；
    将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。
  2. 根据权利要求1所述的方法，其特征在于，在所述HTTP请求需要被等待的情况下，所述依据所述请求信息生成标签表单，包括：
    在所述HTTP请求需要被等待的情况下，判断所述HTTP请求的类型为获取GET请求还是发送POST请求，如果是GET请求，则生成方法为GET、行为为目标统一资源定位符URL且属性为隐藏的标签表单，并从所述目标URL中获取请求信息作为表单项；其中，所述目标URL为所述HTTP请求指向的地址；
    如果是POST请求，则生成方法为POST、行为为目标URL且属性为隐藏的标签表单，并从POST请求的请求体中获取请求信息作为表单项。
  3. 根据权利要求1所述的方法，其特征在于，所述标签表单还设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；
    则所述方法还包括：
    判断所述记录项表示的请求信息的提交次数是否大于预设的提交次数阈值，如果是，则向所述客户端返回所述HTTP请求处理失败的提示信息。
  4. 一种超文本传输协议请求的处理方法，其特征在于，该方法应用于客户端，包括：
    响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器；
    接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息；
    在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。
  5. 根据权利要求1所述的方法，其特征在于，所述标签表单还设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；
    则所述方法还包括：
    接收服务器返回的所述HTTP请求处理失败的提示信息以供显示；其中，所述提示信息为：服务器在判断得到所述记录项表示的请求信息的提交次数大于预设的提交次数阈值的情况下返回的。
  6. 一种超文本传输协议请求的处理装置，其特征在于，该装置集成于服务器上，包括：
    获取模块，用于响应于用户通过客户端提交的超文本传输协议HTTP请求，获取HTTP请求中携带的请求信息；
    生成模块，用于在所述HTTP请求需要被等待的情况下，依据所述请求信息生成标签表单；其中，所述标签表单的表单项包括所述请求信息；
    返回等待页面模块，用于将嵌入了所述标签表单的等待页面返回至所述客户端，以便所述客户端在预设的等待时间到来时，重新将所述标签表单中包括的请求信息提交给服务器。
  7. 根据权利要求6所述的装置，其特征在于，所述生成模块包括：
    判断子模块，用于在所述HTTP请求需要被等待的情况下，判断所述 HTTP请求的类型为获取GET请求还是发送POST请求；
    第一生成子模块，用于在所述HTTP请求为GET请求的情况下，生成方法为GET、行为为目标统一资源定位符URL且属性为隐藏的标签表单；
    第一获取子模块，用于在所述HTTP请求为GET请求HTTP请求为，从所述目标URL中获取请求信息作为表单项；其中，所述目标URL为所述HTTP请求指向的地址；
    第二生成子模块，用于在所述HTTP请求为POST请求的情况下，生成方法为POST、行为为目标URL且属性为隐藏的标签表单；
    第二获取子模块，用于在所述HTTP请求为POST请求的情况下，从POST请求的请求体中获取请求信息作为表单项。
  8. 根据权利要求6所述的装置，其特征在于，所述标签表单还设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；
    则所述装置还包括：
    判断模块，用于判断所述记录项表示的请求信息的提交次数是否大于预设的提交次数阈值；
    返回提示信息模块，用于在所述判断模块的结果为是的情况下，向所述客户端返回所述HTTP请求处理失败的提示信息。
  9. 一种超文本传输协议请求的处理方法装置，其特征在于，该装置集成于客户端上，包括：
    发送模块，用于响应于用户触发的请求信息，将包括所述请求信息的超文本传输协议HTTP请求发送至服务器；
    接收等待页面模块，用于接收服务器返回的、嵌入了标签表单的等待页面以供显示；其中，所述标签表单为：在所述HTTP请求需要被等待的情况下，服务器依据所述请求信息生成的标签表单，所述标签表单的表单项包括所述请求信息；
    提交模块，用于在预设的等待时间到来的情况下，重新将所述标签表 单中包括的请求信息提交给服务器。
  10. 根据权利要求9所述的装置，其特征在于，所述标签表单还设置有记录项，所述记录项用于表示所述客户端向服务器提交同一个HTTP请求的请求信息的次数；则所述装置还包括：
    接收提示信息模块，用于接收服务器返回的所述HTTP请求处理失败的提示信息以供显示；其中，所述提示信息为：服务器在判断得到所述记录项表示的请求信息的提交次数大于预设的提交次数阈值的情况下返回的。
PCT/CN2016/076409 2015-04-01 2016-03-15 超文本传输协议请求的处理方法及装置 Ceased WO2016155491A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510153213.2A CN106161521B (zh) 2015-04-01 2015-04-01 超文本传输协议请求的处理方法及装置
CN201510153213.2 2015-04-01

Publications (1)

Publication Number Publication Date
WO2016155491A1 true WO2016155491A1 (zh) 2016-10-06

Family

ID=57006478

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/076409 Ceased WO2016155491A1 (zh) 2015-04-01 2016-03-15 超文本传输协议请求的处理方法及装置

Country Status (2)

Country Link
CN (1) CN106161521B (zh)
WO (1) WO2016155491A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230107052A1 (en) * 2021-10-06 2023-04-06 Imperva, Inc. Waiting room with zero latency

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106506558A (zh) * 2016-12-29 2017-03-15 东软集团股份有限公司 消息交互的方法、装置及系统
CN106790603A (zh) * 2016-12-29 2017-05-31 东软集团股份有限公司 消息交互的方法、装置及系统
CN107391103B (zh) * 2017-05-27 2021-01-22 北京五八信息技术有限公司 应用程序的登录方法及装置
CN112015483B (zh) * 2020-08-07 2021-12-03 北京浪潮数据技术有限公司 Post请求参数自动化处理方法、装置及可读存储介质
CN112822237B (zh) * 2020-12-28 2022-07-15 北京奇艺世纪科技有限公司 网络请求传输方法及装置
CN114124748B (zh) * 2021-10-15 2024-04-19 青岛海尔科技有限公司 基于idea平台的超文本传输协议接口调试装置及方法
CN117390072B (zh) * 2023-12-07 2024-03-26 深圳市云希谷科技有限公司 一种嵌入式系统中提高网络请求速度的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188146B1 (en) * 1998-12-10 2007-03-06 Canon Kabushiki Kaisha Navigation apparatus capable of generating and displaying information and method therefor
CN101964810A (zh) * 2010-08-25 2011-02-02 北京神州泰岳软件股份有限公司 基于浏览器的实时信息同步方法
CN102438045A (zh) * 2011-12-07 2012-05-02 深圳市深信服电子科技有限公司 Web页面的预取方法、系统以及访问web页面的方法
CN102624761A (zh) * 2011-01-27 2012-08-01 腾讯科技（深圳）有限公司 一种获取图文信息的装置、系统及方法
CN102638454A (zh) * 2012-03-14 2012-08-15 武汉理工大学 一种面向http身份鉴别协议的插件式单点登录集成方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102591889A (zh) * 2011-01-17 2012-07-18 腾讯科技（深圳）有限公司 一种基于移动终端浏览器辅助用户输入的方法及装置
CN102215250B (zh) * 2011-03-30 2013-06-26 广州市动景计算机科技有限公司 用于移动通讯设备终端的自动填表方法、服务器及客户端
CN103379127B (zh) * 2012-04-12 2016-08-17 阿里巴巴集团控股有限公司 服务器与客户端间的数据交互方法及装置
CN103905497B (zh) * 2012-12-27 2018-04-27 腾讯科技（深圳）有限公司 实现第三方应用业务网站登录的方法、装置及应用平台

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7188146B1 (en) * 1998-12-10 2007-03-06 Canon Kabushiki Kaisha Navigation apparatus capable of generating and displaying information and method therefor
CN101964810A (zh) * 2010-08-25 2011-02-02 北京神州泰岳软件股份有限公司 基于浏览器的实时信息同步方法
CN102624761A (zh) * 2011-01-27 2012-08-01 腾讯科技（深圳）有限公司 一种获取图文信息的装置、系统及方法
CN102438045A (zh) * 2011-12-07 2012-05-02 深圳市深信服电子科技有限公司 Web页面的预取方法、系统以及访问web页面的方法
CN102638454A (zh) * 2012-03-14 2012-08-15 武汉理工大学 一种面向http身份鉴别协议的插件式单点登录集成方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230107052A1 (en) * 2021-10-06 2023-04-06 Imperva, Inc. Waiting room with zero latency
US11900182B2 (en) * 2021-10-06 2024-02-13 Imperva, Inc. Waiting room with zero latency
US12572399B2 (en) 2021-10-06 2026-03-10 Imperva, Inc. Waiting room with zero latency

Also Published As

Publication number Publication date
CN106161521B (zh) 2019-09-10
CN106161521A (zh) 2016-11-23

Similar Documents

Publication Publication Date Title
WO2016155491A1 (zh) 超文本传输协议请求的处理方法及装置
CN104427627B (zh) 测试数据获取方法、客户端与服务器
CN110020367B (zh) 一种页面渲染方法及装置
US20150106905A1 (en) Login method for client application and corresponding server
US9386006B1 (en) Authentication mechanism for domain redirection of a representational state transfer (REST)-compliant client
US20170093828A1 (en) System and method for detecting whether automatic login to a website has succeeded
JP2015520436A5 (zh)
US20140136937A1 (en) Providing and procuring worksheet functions through an online marketplace
JP6404816B2 (ja) ウェブページアクセス要求に対する応答の方法および装置
CN104331296A (zh) 交易信息处理方法、装置和系统
CN110336820B (zh) 单点登出方法、装置、设备、存储介质及系统
CN106897336A (zh) 网页文件发送方法、网页渲染方法及装置、网页渲染系统
TWI526028B (zh) A way to implement network access and a web server
CN102447726A (zh) 页面访问方法及系统
CN107797911A (zh) 用于测试http接口的方法和装置
CN102968584A (zh) 一种登录网页的方法和装置
CN104426983A (zh) 网站建设系统及方法
WO2017036043A1 (zh) 钓鱼页面检测方法及系统
CN103024003B (zh) 网页登录方法和装置
CN103716319B (zh) 一种Web访问优化的装置和方法
CN100362788C (zh) 一种网络服务器以及网络服务器与浏览器的数据交互方法
CN102984179A (zh) 一种面向云计算操作系统进行Web服务跨域访问的方法
WO2021077931A1 (zh) 一种注册登录方法、设备和计算机可读存储介质
US10027598B2 (en) Providing network resources based on available user information
CN107332703A (zh) 一种多应用日志的查看方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16771246

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16771246

Country of ref document: EP

Kind code of ref document: A1