HTTP redirection

Abstract

Examples relate to a method of performing HTTP redirection. An intermediate node, such as a home gateway, receives an HTTP request from a client device for a resource located at a content server. An intermediate node, such as a gateway device, determines that the resource is a resource that may be provided by a different source than the content server, such as a resource provided by an agent that is co-located with the intermediate node. The intermediate node then performs network address translation to modify the source port number associated with the HTTP request to one of the predetermined set of source port numbers, and then forwards the HTTP request with the modified source port number to the content server. The content server receives the request and determines that the source port of the HTTP request is one of a predetermined set of source port numbers, and thus sends an HTTP redirection message to the client device, where the HTTP redirection message is sent to a domain associated with the proxy.

Description

Technical Field

[0001] The present invention relates to the field of HTTP redirection. Background Art

[0002] HTTP redirection is used throughout the Internet to enable many services to function, not only due to the resources being moved, but also based on many factors to correctly route requests to the relevant resources. The concept behind redirection is to indicate to the client that the requested resource should be found at a location different from the location to which the original request was directed. The resource can then be requested by the client at the new location indicated by the redirection. For example, a request may be made for video content from a specific content server, but the content may no longer be available there, so the content server may send a redirect message back to the client to direct it to an alternative source where the requested content can be obtained.

[0003] The HTTP redirect method can indicate a temporary redirect or a permanent redirect, so that the redirect response can be cached on the client for use with another request. The redirect response can also be cached on the client for a specified amount of time to reduce network traffic and speed up subsequent requests.

[0004] For normal service availability detection, out-of-band mechanisms are often used to provide information about service discovery. This can involve a database containing service locations and an update mechanism when service availability changes. However, this requires significant management and interoperability between the service provider and the system doing the availability lookup. In addition, when scaled up to large sizes, the cost of such a system will often be prohibitive. Therefore, systems often wish to establish an in-band communication method to determine service availability.

[0005] When a client requests content from an online source using a URI (Universal Resource Identifier) ​​or other identifier, the request may pass through several control domains before it is processed on the final destination device. This is usually an automated process based on a list of rules kept on an intermediary device, which is usually pre-configured and static in nature, matching the request on multiple factors such as source IP, domain, resource, and load balancing policy.

[0006] The redirection process from the source device issuing the request and the final destination device becomes a chain of conditional operations, where each step includes a redirection message sent to the client, the redirection processed by the server, or the final processing of the request.

[0007] The redirect message sent to the client will typically signal with an HTTP 30x-based response, whereby the client will then make subsequent requests based on the information in the redirect message, continuing the redirect chain. The redirect processed by the server will pass the request directly to the next device in the chain, thereby moving to the next step in the chain. Finally, processing of the request on the final destination device will result in the expected response being returned to the source client device.

[0008] As described above, the process by which the intermediaries in the redirect chain make decisions is typically based on simple logic, where the IP address of the requester and the requested resource and domain are used to determine the correct action to take. This may involve possibly using regular expressions to identify an exact match in a database or lookup table, or a partial match of the requested resource; alternatively, in the case of an IP, a longest prefix match may also be used. The static lookup described is generally satisfactory for the operation of many services, however, when more advanced services are in operation, improvements to this functionality may be beneficial.

[0009] U.S. patent application US20050265252A1 relates to methods, systems and media for subdividing temporary port ranges and allocating ports from the subdivided temporary port ranges based on, for example, application load, expected and / or actual load conditions, quality of service, performance guarantees, application starvation, process priority, user identification, group identification, process name, etc. Summary of the invention

[0010] An object of examples of the present invention is to provide an improved HTTP redirection method.

[0011] According to an example of the present invention, a method for managing HTTP requests is provided, the method comprising:

[0012] Receiving, at a network module, an HTTP request for a resource located at a first server, wherein the HTTP request is from a client device;

[0013] determining, by the network module, that the request should be redirected to a second server, and then modifying a source port number associated with the HTTP request to a number from a predetermined set of source port numbers;

[0014] forwarding, by the network module, the HTTP request with the modified source port number to the first server;

[0015] Receiving, by the first server, the forwarded HTTP request; and

[0016] The first server determines (222) that the source port number of the HTTP request is a number from the predetermined set of source port numbers, and then sends an HTTP redirect message to the client device, wherein the HTTP redirect message is sent to a domain associated with the second server.

[0017] The step of determining, by the network module, that the request should be redirected may include checking whether the request satisfies a predetermined criterion. The predetermined criterion may include a list of target IP addresses, and the target IP address of the request must match one of the target IP addresses in the list. The predetermined criterion may include a list of domains, and the domain of the request must match one of the domains on the list.

[0018] The first server may be a content server. The second server may be a proxy. The network module may be a gateway device.

[0019] The second server may be located where the network module is located.

[0020] According to another example of the present invention, a system for managing HTTP requests is provided, the system comprising:

[0021] a network module adapted to receive an HTTP request for a resource located at a first server, wherein the HTTP request is from a client device, and determine that the request should be redirected to a second server, and then modify a source port number associated with the HTTP request to a number from a predetermined set of source port numbers, and the first module is further adapted to forward the HTTP request with the modified source port number to the first server; and

[0022] A first server, wherein the first server is adapted to receive a forwarded HTTP request, and determine that a source port number of the HTTP request is a number from the predetermined set of source port numbers, and send an HTTP redirect message to the client device, wherein the HTTP redirect message is sent to a domain associated with the second server.

[0023] The redirection depends on the existence of an intermediate node or a service available on an intermediate node, which is located between the client device making the request and the original destination of the request. The intermediate node can be a proxy located on a residential gateway device, a client device, or some other intermediate device.

[0024] Advantageously, separate out-of-band signaling of the availability of the intermediate nodes is not required, as the TCP source port number associated with the request itself is used to signal the need for in-band redirection. Typically, adding out-of-band signaling adds complexity and the need to identify the service and maintain state can present scalability issues for large volumes of service. A separate system is also required for managing the additional signaling. Identifying the service can also be a problem if encryption is used, making it difficult to inspect the request.

[0025] The setting of the source port number utilizes the network address translation (NAT) function found in many network devices (such as home gateways), wherein the source port number can be set to a value within a predetermined set or range. This can be done conditionally on a specific gateway application or proxy that is available at the gateway device to receive the redirected request.

[0026] The source port number setting can also be applied to the client device instead of the gateway device or other intermediate device.

[0027] The described method provides in-band identification of the need for redirection without modifying the HTTP request itself. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] For a better understanding of the present invention, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0029] Figure 1 is a system diagram showing the main components of an example of the present invention;

[0030] Figure 2 is a flowchart outlining the steps of an example of the present invention; and

[0031] Figure 3 is a flow chart summarizing other steps of an example of the present invention. DETAILED DESCRIPTION

[0032] The present invention is described herein with reference to specific examples. However, the present invention is not limited to such examples.

[0033] An example of the present invention provides a method for performing HTTP redirection. An intermediate node such as a home gateway receives an HTTP request for a resource located at a content server from a client device. An intermediate node such as a gateway device determines that the resource is a resource that can be provided by a source different from the content server, such as a resource provided by a proxy co-located with the intermediate node. Then, the intermediate node performs network address translation to modify the source port number associated with the HTTP request to one of the source port numbers in a predetermined source port number set, and then forwards the HTTP request with the modified source port number to the content server. The content server receives the request and determines that the source port of the HTTP request is one of the predetermined source port number set, and therefore sends an HTTP redirect message to the client device, wherein the HTTP redirect message is sent to a domain associated with the proxy. After receiving the redirect message, the client sends an updated HTTP request pointing to the domain identified in the redirect message. Therefore, when certain conditions are met (such as when a proxy can be used to provide the requested service), the HTTP redirection is initiated by the intermediate node without any further signaling or modification of the original HTTP request itself.

[0034] Examples of the present invention will now be presented with reference to a content delivery system.

[0035] Figure 1 An exemplary content delivery system 100 is shown. System 100 includes a client device 102, a gateway device 104, a content server 106, a DNS server 108, and a proxy 110. As a result of a content request received from client device 102, content server 106 provides a response to client device 102. In this example, DNS server 108 and proxy 110 are located within gateway device 104. For example, DNS server 108 and proxy 110 may be implemented as software modules within gateway device 104. However, DNS server 108 and proxy 110 may be located elsewhere, such as on client device 104. Client device 102 may be, for example, a television set-top box, a laptop computer, a tablet computer, or a smart phone.

[0036] Client device 102 uses given resource uniform resource indicator (URI) to make HTTP request for content.In this content delivery example that client device 102 wants to use the protocol such as HTTP live streaming (HLS) to request video content, this request can be for video list or playlist file (such as .m3u8 format playlist file), and described video list or playlist file lists specific video content fragment and where can obtain these video content fragments.However, this request can be for some other resources such as software update, audio file or any other data.Then, using DNS server 108, through normal DNS lookup process, domain name from URI is resolved to IP address.Then, this IP address is used to send HTTP request for resource identified in URI to content server 106 located at resolved IP address.In this example, IP address is the IP address of content server 106, and HTTP request is routed to gateway device 104 from client 102 using default route assignment in client routing table.

[0037] Although in certain examples the requests made by the client device 102 have been described as HTTP requests, the method may also be applied to client devices 102 making HTTPS requests.

[0038] The gateway device 104 then performs network address translation (NAT) on the received request to allow IP packets with private addresses to be routed on the public Internet. The TCP source port number in this example will typically be assigned a random number between 1024 and 49151. However, when a request compatible with a service provided by the proxy 110 is detected, the gateway device 104 in the example of the present invention sets the TCP source port number to a smaller predetermined set or range of source port numbers. In the case of this example, the service may be a video streaming service for content stored at the proxy 110 rather than at the content server 106. Examples of such services are described in the applicant's international applications WO2020 / 173878 and WO2020 / 173984, in which a client device requests content to be provided via unicast from a content server, but the content is provided via unicast by a proxy that receives the same content via multicast.

[0039] The detection of the request for compatible services that can be provided by the proxy 110 can be achieved in a variety of ways, all of which effectively check whether the request meets certain predetermined criteria. The first way is to check the target IP address and check whether it matches the predetermined target IP address, which can be pre-configured or updated by the proxy 110. Another way is to use the domain name for the request, which can be detected by the server name identifier (SNI) or by capturing and recording the DNS lookup results performed by the client 102, and check to see whether it matches the predetermined domain. Other criteria can also be used for specific content types, such as using the destination port to identify the type of business or service. In all cases, the purpose is to detect certain criteria in the request, and then use the described examples of the present invention to process the request. The criteria can be stored in a list at the gateway device 104 and managed by the proxy 110.

[0040] The NAT-processed IP packets will then be routed from the gateway device 104 through the Internet and received by the content server 106. The content server 106 then determines whether the HTTP request should be redirected to an alternative service, such as a service provided by the proxy 110. This can be done by checking the source port number on the received IP packet and determining whether the source port number falls within a predetermined source port number set. If so, the content server 106 responds with an HTTP redirect response message with a URI that is configured to enable the requested playlist file to be delivered using the proxy 110. Subsequent requests for content segments can then be provided from the proxy 110. This is implemented using relative addressing for segment notations within the playlist file; where only the resource path of the segment is recorded and appended to the original domain used to obtain the playlist file. However, requests received at the content server 106 with a source port number outside the predetermined source port number set will be provided with the requested resource from the content server 106, or redirected to another location where the resource can be obtained.

[0041] There may be situations where redirection occurs when the service at proxy 110 is not actually active. This may occur if gateway device 104 is not operating in accordance with the present invention, but still randomly sets the source port number to one that falls within a predetermined set of source port numbers. However, such a request will be a lower number compared to the number of correctly redirected requests.

[0042] The important point to emphasize is that HTTPS is used for most services on the Internet, which essentially prevents the content of the request from being seen by intermediate devices. Therefore, the content of the HTTPS request made by the client 102 will not be visible to the gateway device 104, only specific header information (such as SNI) is visible.

[0043] In an alternative approach, gateway device 104 and proxy 110 may instead reside on client device 102 as software modules.

[0044] This same general method of selecting a source port number for one of the predetermined set may also be applied when the proxy 110 resides elsewhere in the network 100 other than the gateway device 104 or even the client device 102 .

[0045] The following will refer to Figure 2 and Figure 3 A working example of the present invention is described in more detail with reference to the flow chart of FIG.

[0046] Figure 2 Flowchart 200 is shown, where processing begins at step 202 .

[0047] In step 202, the client device 102 makes an HTTP request to a specific resource, which in this example has the URI: www.example.com / master.m3u8 The manifest file.

[0048] In step 204, client device 102 determines the IP address to which the request is to be sent based on the domain name. Therefore, client device 102 sends a DNS request to DNS server 108 for www.example.com.

[0049] In step 206, client device 102 receives a DNS response from DNS server 108, the DNS response having a DNS address for the domain www.example.com The IP address of the server, which in this example is resolved to 1.1.1.1.

[0050] In step 208 , using the IP address determined in step 206 , client device 102 sends an HTTP request (URI: www.example.com / master.m3u8) to content server 106 .

[0051] In step 210 , the gateway device 104 receives the request due to the default IP routing installed on the client device 102 .

[0052] In step 212, gateway device 104 checks to see if the HTTP request should trigger a redirection to a service at proxy 110. This check may be performed using, for example, an IP lookup or domain match against a list stored at gateway device 104. Since SNI is provided in unencrypted form in the request header, this is possible even when processing HTTPS requests. For example, the list may be used to identify an IP address (e.g., 1.1.1.1) or domain (e.g., 1.1.1.1) of a request that should be redirected to a service at proxy 110. www.example.com ). Such a list may be managed by the proxy 110, which can update the list based on what services are available at the proxy 110 at any given time.

[0053] If there is an alternative service available at the proxy 110, then the process proceeds to step 214 (which is performed for the purposes of this example). In step 214, as part of the network address translation service (NAT) process, the gateway device 104 sets the TCP source port number to a number from a predetermined set of source port numbers. This can be done randomly. For example, the predetermined set of source port numbers can be from 49141 to 49151 (compared to the commonly available range of 1024 to 49151). Then, the process proceeds to step 218.

[0054] However, if no alternative service is available from step 212, then processing proceeds to step 216. In step 216, as part of the NAT process, gateway device 104 sets the TCP source port number to a random value between 1024 and 49140, which is the standard random assignment range used in NAT (except that it excludes the predetermined set of source port numbers used by gateway device 104 in step 214). Processing then proceeds to step 218.

[0055] In step 218, after completing the modified NAT process of step 214 or 216, gateway device 104 forwards the request to content server 106 at IP address 1.1.1.1.

[0056] In step 220 , an HTTP request is received at the content server 106 .

[0057] In step 222, content server 106 checks to see if the TCP source port number of the request is one of a predetermined set of numbers 49141 to 49151 to indicate the availability of an alternative service on proxy 110. If the source port number is not one of the predetermined set, processing moves to step 224. If the source port number is one of the predetermined set, processing moves to step 228.

[0058] In step 224, the source port is outside of the predetermined set, so the requested resource (playlist) is sent back from the content server 106 to the client 102 (or redirected according to normal operation).

[0059] In step 226, client 102 receives the response from content server 106 and processes the response as usual.

[0060] In step 228, the source port number is found to be one of the predetermined set of content server 106, so content server 106 sends an HTTP redirect message back to client 102 using a URI with a specific domain associated with the alternative service on proxy 110. In this example, the redirect URI is: proxy.home.gateway.com / master.m3u8. The process then moves to Figure 3 300 of the flowchart.

[0061] In the above example, a single set of source port numbers is used to redirect to a single domain on proxy 110. However, different sets of source port numbers may be used to redirect to different instances of proxy 110. For example, one set of source port numbers may be used to redirect to a first service (e.g., a live football streaming service) on a first instance of proxy 110, while a second, different range of source port numbers may be used to redirect to a second service (e.g., a live news streaming service) on a second instance of proxy 110.

[0062] Figure 3 A flow chart 300 is shown outlining the steps followed once the client device 102 receives a redirect from the content server 106 .

[0063] In step 302 , the client device 102 receives a redirect from the content server 106 .

[0064] In step 304, the client device 102 initiates an HTTP request to the redirected URI, which in this example is proxy.home.gateway.com / master.m3u8.

[0065] In step 306 , the client device 102 initiates the process of discovering the IP address to which the new request is to be sent, and the client device 102 sends a DNS request for the domain (proxy.home.gateway.com) to its configured DNS server 108 .

[0066] In step 308 , DNS server 108 responds to the DNS request with the IP address of proxy 110 , which in this example is 192.168.1.1 . The IP address is received by client device 308 .

[0067] In step 310 , the client device 102 sends an HTTP request (URI: proxy.home.gateway.com / master.m3u8) to the IP address resolved in step 308 of 192.168.1.1.

[0068] In step 312, the proxy 110 receives the HTTP request, performs any necessary processing, and then sends a response to the client 102. In this case, the response will be the requested playlist file master.m3u8.

[0069] In step 314 , the client device 102 receives a response from the proxy 110 and passes the resource data to the relevant application module.

[0070] Finally, in step 316, since the initial request was for the master.m3u8 playlist file, subsequent requests for related content segments referenced within the playlist file will be automatically directed to the proxy.home.gateway.com domain without requiring a redirect from the content server 106. This is due to the relative addressing scheme used within the playlist file.

[0071] Generally, it should be noted herein that, although examples of the invention are described above, several changes and modifications may be made to the described examples without departing from the scope of the invention as defined in the appended claims. Those skilled in the art will recognize modifications to the described examples.

Claims

1. A method for managing HTTP requests, the method comprising: Receiving (210) at a network module an HTTP request for a resource located at a first server, wherein the HTTP request is from a client device; determining (212, 214), by the network module, that the request should be redirected to a second server, and then modifying the source port number associated with the HTTP request to a number from a predetermined set of source port numbers; forwarding (218), by the network module, the HTTP request with the modified source port number to the first server; Receiving (220) the forwarded HTTP request by the first server; The first server determines (222) that the source port number of the HTTP request is a number from the predetermined set of source port numbers, and then sends (228) an HTTP redirect message to the client device, wherein the HTTP redirect message is sent to a domain associated with the second server.

2. The method according to claim 1, wherein: Determining, by the network module, that a request should be redirected includes checking whether the request satisfies predetermined criteria.

3. The method according to claim 2, wherein: The predetermined criteria include a list of target IP addresses, and the target IP address of the request must match one of the target IP addresses from the list.

4. The method according to claim 2, wherein: The predetermined criteria include a list of domains, and the requested domain must match one of the domains on the list.

5. A method according to any one of the preceding claims, wherein: The first server is a content server.

6. A method according to any one of the preceding claims, wherein: The second server is a proxy.

7. A method according to any one of the preceding claims, wherein: The network module is a gateway device.

8. A method according to any one of the preceding claims, wherein: The second server is located where the network module is located.

9. A system for managing HTTP requests, the system comprising: a network module adapted to receive an HTTP request for a resource located at a first server, wherein the HTTP request is from a client device, and the network module is adapted to determine that the request should be redirected to a second server, and then modify a source port number associated with the HTTP request to a number from a predetermined set of source port numbers, and the first module is further adapted to forward the HTTP request with the modified source port number to the first server; and A first server, wherein the first server is adapted to receive a forwarded HTTP request, and determine that the source port number of the HTTP request is a number from the predetermined set of source port numbers, and send an HTTP redirect message to the client device, wherein the HTTP redirect message is sent to a domain associated with the second server.

Images