Electrical computers and digital processing systems: multicomput – Computer network managing
Reexamination Certificate
2001-01-31
2004-12-28
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer network managing
C709S225000, C709S227000
Reexamination Certificate
active
06836795
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The present invention relates to mapping connections and protocol specific resource identifiers. More specifically, the present invention relates to a front-end server providing access to content stored on a back-end server by mapping the connection between a client system and the front-end server with the corresponding connection between the front-end server and the back-end server. As needed, protocol specific resource identifiers are generated to match the protocol associated with the connection between the client system and the front-end server.
2. Background and Related Art
At times, a client system on an insecure network, such as the Internet, may request hypertext transfer protocol (“HTTP”) content from a back-end server that is operating on a relatively secure private network, such as a corporate intranet. It may also be the case that such HTTP requests made by the client are encrypted to prevent unwanted data interception. Conventionally, the back-end server would decrypt the request, processes the request, encrypt data associated with the request, and send the data to the client system. However, encrypting and decrypting HTTP data is computationally expensive and as result drains resources a back-end server might use to perform other functions, such as query a database or other configured tasks.
Where multiple back-end servers provide related content, a front-end server may be used as a common point of access. Client systems direct requests to the front-end server and the front-end server forwards the request to the appropriate back-end server. This allows for content to be distributed and enables load balancing across the servers where the content is available. For example, email stores for an organization may be distributed over several back-end servers, with a single front-end server allowing all stores to be accessed using a single resource identifier, such as “http://www.company.com/email”. When the front-end server receives a request for email, the request is directed to the back-end server where the corresponding email stored is located.
To prevent eavesdropping and insure data integrity, communication between the client systems and the front-end server may use a secure protocol. In contrast, the communication between the front-end server and the back-end server may not need to use a secure protocol because the communication link itself may not subject to tampering, such as a communication link that is isolated from external contact. However, using a secure protocol between the client and front-end server with an insecure protocol between the front-end server and back-end server leads to certain problems.
Consider for example, providing email using HTTP for communication between the back-end server and the front-end server, and using HTTPS (HTTP with a secure sockets layer or SSL) for the communication between the front-end server and the client system. At login, the client system submits an HTTPS request to view the client system's inbox. The front-end server receives the request, performs the appropriate decryption, and directs the request to the back-end server where the inbox is located. In response, the back-end server generates an HTTP version of the inbox (i.e., the uniform resource locators (“URLs”) for the inbox specify “http” as the protocol). The response is returned to the front-end server and sent to the requesting client system. Upon selection of a URL, the client system generates a request for the corresponding email. However, because the URL specifies HTTP as the protocol, the request to the front-end server is made over an insecure connection. Obviously, this is not what the client system intended since the client system initiated contact using a secure protocol.
Moreover, requesting email content over an insecure connection is a further problem because the front-end server may be configured to communicate over external insecure networks only using protocols such as HTTPS. Thus, a front-end server may not be configured to use insecure protocols on insecure networks. As a result, the front-end server rejects any requests from the client that use an insecure protocol. Alternatively, the front-end server may be configured to allow insecure requests for some data, such as publicly accessible Web pages, while rejecting requests for more sensitive content, such as email content. In either case, the potential exists for the front-end server to reject a request submitted over an insecure connection.
Although communicating between the front-end server and the back-end server with the same protocol that is used between the client system and the front-end server may solve the HTTP URL problem, this approach is undesirable because it requires the back-end server to encrypt the content it provides. As noted above, this encryption may be computationally expensive and may serve no useful purpose if the connection between the front-end server and the back-end server is not subject to attack. Furthermore, the front-end server is required first to decrypt the content it receives from the back-end server, using the key negotiated between the front-end server and the back-end server, and then to re-encrypt the content, using the key negotiated between the front-end server and the client. To avoid the unneeded encryption/decryption operations, the front-end server could parse the content it receives from the back-end servers and modify protocol specific resource identifiers as needed. However, similar to the extra encryption/decryption processing, parsing content at the front-end server for protocol specific resource identifiers is computationally expensive and requires storing content, at least temporarily, on the front-end server. For these reasons and others, parsing content at the front-end server is also undesirable.
Therefore, systems, methods, and computer program products are desired for mapping connections and protocol specific resource identifiers, where the systems, methods, and computer program products impose minimal resource requirements on the front-end server and back-end servers.
SUMMARY OF THE INVENTION
The principles of the present invention provide for mapping connections and protocol specific resource identifiers. When a front-end server receives a request that is ultimately directed to a back-end server, the front-end server performs certain operations on the request before forwarding it to the back-end server. First, the front-end server decrypts the request as needed. Second, the front-end inserts a protocol element into the request sent to the back-end server to notify the back-end server of the protocol used in the client's request to the front-end server. When the back-end server retrieves data associated with the request, the back-end server passes the content to the front-end server. When received, the front-end server sends the content to the client according to the protocol used in the client's request. The back-end server generates protocol specific resource identifiers within the content that are consistent with the protocol element or information included with the request for content, even though the front-end server and the back-end server may use another protocol in communicating with each other. For example, the client system and the front end server may communicate using HTTPS, while the front end server communicates with the back end server using HTTP. Because the front-end server performs any needed encryption and decryption for requests only once, the resources of the front-end server and back-end servers are freed up to perform other tasks. Also, the front-end server will not reject subsequent requests for content that the client generates based on the selection of protocol specific resource identifiers in content that has been received. Because the back-end server generates resource identifiers consistent with the protocol used between the client system and the front-end server, requested content may be sent to the client system even where the front
Deen Brian J.
Hopmann Alexander I.
Soderberg Joel M.
Maung Zarni
Microsoft Corporation
Nydegger Workman
Patel Ashok B.
LandOfFree
Mapping connections and protocol-specific resource identifiers does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mapping connections and protocol-specific resource identifiers, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mapping connections and protocol-specific resource identifiers will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3330569