1. Field of the Invention
The present invention relates to a method and apparatus for using a bookmark to retrieve a web page when the URI (Uniform Resource Identifier) used in the request that led to the creation of the bookmark resulted in a redirection response.
2. Description of the Related Art
Web browsers and web servers communicate through the Hypertext Transfer Protocol, HTTP. One feature of this protocol is redirection: A web server can service a request with one URI (the request URI) by redirecting the browser to another URI (the redirection URI) at which the information sought by the original request can be retrieved. Specifically, a browser sends an HTTP request to the request URI and receives a redirection response. The redirection response contains a status code in the range 300-399, indicating that the request has been redirected, and specifies the redirection URI. Upon receiving such a response, the browser issues an HTTP request to the redirection URI. (This process may be repeated.)
When a current web browser receives a redirection response, it replaces the request that had been displayed in the browser address window with the redirection URI. If the user of the browser bookmarks the pages (a process referred to in some browsers as adding the page to list of “favorites”), it is the redirection URI that is recorded in the bookmark. This is unfortunate, because the request URI is often more stable than the redirection URI. That is, the redirection URI may cease to function, and the request URI may continue to redirect the browser to an appropriate page. There are several reasons this might be the case:
In each of these situations, it would be better for a browser to bookmark the request URI, but current browsers bookmark the redirection URI.
There are also situations in which it is preferable to bookmark the redirection URI, as when a website has been permanently moved to a new server, or a website has been reorganized, or a web server has been renamed (e.g., because the name of the corporation hosting the server has changed.) In these cases, the request URI is obsolete, and it is preferable (for reasons of efficiency and because the obsolete URI may one day disappear) to use the redirection URI in all future searches.
Internet Engineering Task Force (IETF) Request for Comments (RFC) 2616, defining version 1.1 of the Hypertext Transfer Protocol (HTTP) (at http://www.ietf.org/rfc/rfc2616.txt), specifies that a server should return a status code of 301 to indicate that the resource originally identified by the request URI has been permanently assigned a new URI that should be used in all future requests; and a status code of 302 or 307 to indicate that the resource originally identified by the request URI resides temporarily under a new URI, but that the request URI should continue to be used in future requests. Note 28 “Common User Agent Problems,” published by the World Wide Web Consortium (W3C), (at http://www.w3.org/TR/cuap) enumerates common ways in which browsers fail to conform to RFC 2616, and specifically asserts, “The user should be able to bookmark, copy, or link to the original (persistent) URI or the result of a temporary redirect.” Note 28 states that, in contrast to this advice, “user agents” (i.e., browsers) “usually show the user (in the user interface) the URI that is the result of a temporary (302 or 307) redirect, as they would do for a permanent (301) redirect.”
To enable the use of bookmarks to retrieve a web page that was retrieved earlier using a given request URI, the current invention associates that request URI with a bookmark stored in a browser; later reference to the bookmark initiates retrieval of the web page identified by the URI associated with that bookmark. In one aspect of this invention, the association between the request URI and the bookmark is distributed between the browser and the web server. In a second aspect of this invention, the association is stored entirely in the browser.
Thus, according to a first aspect of the invention, there is provided a system and method of retrieving, in response to a later HTTP request by a requester, a web page retrieved by a browser device in response to an earlier redirected HTTP request, the method comprising:
at the server device, generating a redirection response to said earlier redirected HTTP request, and generating and storing a record associating the redirection URI in said redirection response with the request URI in said earlier redirected HTTP request;
storing, at said browser device, said redirection URI in a bookmark;
retrieving, at said browser device, the URI associated with said bookmark by issuing said later HTTP request, using the redirection URI stored in said bookmark as the request URI of said later HTTP request;
receiving, at said server device, said later HTTP request and searching for a record associating the request URI of said later HTTP request with the request URI of some earlier redirected HTTP request;
upon finding such a record, said server device processing said later HTTP request as if its request URI were said request URI of some earlier redirected HTTP request in said found record, wherein a web page identified by the request URI of said earlier redirected HTTP request is retrieved through said bookmark.
Further to this aspect of the invention, a unique record associating the given redirection URI returned in response to a request with the given request URI is generated for each user of the browser device. Thus, in response to receiving, at the server device, a given HTTP request with a given request URI from a given user, the server device:
searches for the record of the given URI having been returned as a redirection URI in response to a request from the given user with some request URI; and,
upon accessing the record, processes the given HTTP request as if it contained the given request URI.
Furthermore, the server device that generates a record associating the given redirection URI returned in response to a request with the given request URI may be the same as or different from the server device receiving the given HTTP request with a given URI.
According to a further aspect of the invention, there is provided a method of bookmarking a web page by a browser device as a result of issuing an HTTP request with a given request URI that resulted in a redirection response from a server device. The method comprises:
receiving an HTTP response from the server device, and
creating, at the browser device, at the initiation of the user of the browser device, a bookmark for the given request URI in the HTTP request, even if the request was redirected to another URI by the server device.
Further in accordance with this aspect of the invention, prior to the creating, the steps of:
determining whether the HTTP response received is a redirection response from the server device; and, in response to the determining,
enabling the browser device to create, at the initiation of the user of the browser, one of: a bookmark referring to the original given request URI that was subject to redirection, or a bookmark referring to the redirection URI in the received HTTP response.
Additionally, the present invention is directed to a system for retrieving web pages comprising:
a computing device for receiving an HTTP request with a given request URI;
a means implemented in the computing device for determining whether a given request URI results in a redirection response and providing a redirection URI in response to a given request that results in the redirection;
a means associated with the computing device for generating a data structure associating the given redirection URI returned in response to a request with the given request URI;
a storage means for storing the generated data structure;
a browser device for storing a bookmark associated with a URI, the redirection URI being returned by the computing device in the bookmark, the browser device retrieving the URI associated with the bookmark by issuing an HTTP request including the redirection URI stored in the bookmark; and,
a means implemented in the computing device for searching for the data structure of the given URI having been returned as a redirection URI in response to a request with a request URI, and, upon accessing the data structure, initiating the computing device to process the given HTTP request as if it contained the given request URI,
wherein a web page identified by the given request URI associated with the given stored bookmark is retrieved.
Advantageously, the invention enables provisioning of a service that generates HTTP responses in response to HTTP requests, wherein the service comprises:
receiving HTTP requests at a computing device, each HTTP request associated with a given original request URI;
determining, at the computing device, whether a given request URI results in a redirection response and providing a redirection URI in response to a given original request that results in the redirection; and
responding at the computing device to any subsequent HTTP request from the same requestor in which the request URI is the given redirection URI as if the request URI in the subsequent HTTP request were replaced by the given original request URI.
The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
The key to using a bookmark to retrieve a web page that was retrieved earlier using a given request URI is to establish an association between a bookmark and that request URI. In the distributed aspect of this invention, this association is maintained partly in a web browser and partly on a web server. In the browser-only aspect of this invention, this association is maintained exclusively in a browser.
The distributed aspect can be implemented entirely by changes at the web server, using current web browsers. It can be viewed as a server-side fix to the problem of web browsers that do not distinguish among redirection status codes.
If the user of a web browser 110 requests the retrieval of the content associated with a bookmark, the web browser will send to the web server 120 the URI that bookmark mapping 130 associates with the bookmark. If the URI is one that the browser obtained, on behalf of the same user, as the result of a previous redirection, the past-redirections relation 150 will have a record of the previous redirection, including the original request URI, and the web server will process the new request as if it contains the original request URI. If the corresponding web content has moved since the previous redirection, this processing may result in a new redirection to a different redirection URI.
The activity diagram in
This URI redirection-management functionality implemented at the server device is embodied as a service and comprises all of the computer readable instructions, data structures, program modules, objects, and other configuration data for providing this redirection-management service for the benefit of the users.
It is possible for the same user to issue HTTP requests with two distinct request URIs, both of which are redirected to the same redirection URI. There are various ways in which the web server can deal with such an eventuality. One approach is to save only the most recent tuple in the past-redirections relation for a given combination of user and redirection URI. Another approach is to save all such tuples, and return a dynamically generated web page prompting the user to select from among the various request URIs. (The past redirection URI may also be presented as an option.)
It will be recognized that the past-redirections relation 150 can be replaced by a past-redirections mapping from redirection URIs to corresponding request URIs, without distinguishing among the various users whose requests were redirected; this implementation is more efficient in terms of time and space, but potentially less accurate. It will be further recognized that rather than constructing such a past-redirections mapping incrementally each time it returns a redirection response, the web server 120 can simply use the inverse of the future-redirections mapping.
The browser-only aspect of the current invention entails a decision, at the time the user of the browser requests the bookmarking of a web page, to bookmark either the request URI or the redirection URI.
In the case of a request to perform a search using a given request URI, the browser performs a step 315 in which it sends an HTTP request to the web server containing the request URI. In a step 320, the browser receives an HTTP response from the web server, and in a step 325 the browser examines the HTTP response to determine whether it is a redirection response. In the case of a redirection response, the browser executes a step 330 to issue a new HTTP request using the redirection URI, and loops back to repeat the processing starting at 320. The loop enables the browser to follow a chain of multiple redirections. In the case of an HTTP response other than a redirection response, a step 335 performs the processing appropriate for that response, which is beyond the scope of the current invention, completing this iteration of the event-loop body.
In the case of a request to bookmark the currently displayed web page, the browser executes a decision step 340 to determine which URI should be bookmarked, the original request URI sent in step 315 or, the final redirection URI processed in step 330. In the former case a step 345 bookmarks the request URI, and in the latter case a step 350 bookmarks the redirection URI, completing this iteration of the event-loop body.
There are several ways in which a browser can execute decision step 340. A degenerate case of the decision step is simply to use the request URI in all cases. As explained herein, this is often, but not always, the best response. The following alternatives offer more control to the user of the browser:
It will be recognized that there are many variations possible in the kind of control the user of the browser is given over the selection of a URI to be bookmarked, and many variations in the design of a user interface to communicate the user's decisions. The examples listed above are illustrative, and not meant to be exhaustive.
While the invention has been particularly shown and described with respect to illustrative and preformed embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention which should be limited only by the scope of the appended claims.