WO2003094047A2

WO2003094047A2 - Accelerated transmission of hypertext documents

Info

Publication number: WO2003094047A2
Application number: PCT/DE2003/001379
Authority: WO
Inventors: Andreas Dangberg
Original assignee: Siemens Aktiengesellschaft
Priority date: 2002-04-30
Filing date: 2003-04-29
Publication date: 2003-11-13
Also published as: EP1509860A2; DE10219390B4; WO2003094047A3; DE10219390A1; US20060122844A1

Abstract

When a HTML page is requested, an indicator is set by a browser and is used to enable the server to send back an archive, in the place of the HTML page, which is unpacked by the browser in the cache. The archive contains, for example, the images which are required by said page and which are retrieved from the cache such that only one network transfer is required per page. The invention is compatible with previous operations, especially by using content negotiation according to RFC 2295 or remote variant selection according to RFC 2296.

Description

Accelerated transmission of hypertext documents

The invention relates to the accelerated transmission of hypertext documents, in particular HTML pages with the HTTP protocol.

The use of the network known as the Internet with 'browsers', the marking languages HTML and the HTTP protocol is generally known in detail to the person skilled in the art.

When HTML pages are called up, the authors of the pages are making increasing use of graphics and other embedded components. This means that the HTML page addressed by a URL is first retrieved from the server specified therein and transferred from the server to the browser. After receiving the page (or a first part) it is analyzed according to the syntax rules of HTML, with the elements being marked by tags. Graphics are embedded by the IMG tag. With the 'SRC =' parameter, the IMG tag contains the address of a graphic or image file to be loaded. The file is then called up from the server for each of these elements, that is, a request-response pair of the HTTP protocol is carried out for each image.

The long time it took to build an HTML page is compensated for by various measures. On the one hand, the HTTP / 1.1 protocol allows a connection to be kept open, so that the connection setup and clearing down are not necessary. Furthermore, the browser regularly has a cache ('cache.'), From which previously loaded elements can be extracted. However, the latter is devalued by the fact that the graphic designers prefer to use different graphics on each page. In addition, the buffer memory can only buffer elements of identical addresses; when activating a reference that leads to another computer, all graphics are reload when visiting this page for the first time. The problem is only barely visible to professional users due to the high computing speeds and fast network connections today. However, it is found that private users are also no longer willing to wait a long time for a page to be built and may no longer consider a commercial offer if the loading time is subjectively too slow.

For the special class of embedded objects called JAVA applet, the HTML tag provides that not only the name of the JAVA class to be executed, but also the address of a JAR archive in which the class is to be contained is specified. The browser then loads the entire archive and takes the class and the objects it needs from the archive.

Based on this, an improvement is proposed in US Pat. No. 6,026,437. If, in the traditional solution, the HTML document and then the JAR archive have to be loaded in two separate calls, the font suggests that the hypertext link ('link') points to a JAR archive that does exactly that an HTML document using the JAR archive. However, this solution requires changes to all browsers beforehand, since the optimization is caused by a changed syntax of the references.

The object of the present invention is to provide a solution with which all objects required by one side can be transmitted with a network transfer and which is nevertheless compatible with the previous use. In particular, the HTML page should remain unchanged; only the server and browser are supplemented in such a way that an improved server with an improved browser increases efficiency, but the remaining three combinations remain functional. The solution uses the possibility that the browser sets an indicator when the HTML page is requested, which is ignored by previous servers and is used by new servers to send an archive containing the HTML page instead of the HTML page , In contrast to a JAR archive, this archive is not set as a whole in the buffer memory, but is unpacked and loaded into the buffer memory (element). The content of the archive can contain any elements that can be addressed via URL, which are then used automatically by the buffer memory mechanism. In contrast to the prior art mentioned, it is therefore not necessary that all elements contained in the page are contained in the archive. In particular, it will often make sense not to integrate a JAR archive and to load it separately. It can also contain elements that are only indirectly referenced, for example, if the page refers to another page, which in turn contains graphics and these are already transferred on the first page.

In summary, the invention is as follows: When an HTML page is requested, the browser sets an indicator on the basis of which the server sends an archive instead of the HTML page, which the browser unpacks into the cache. The archive contains, for example, the images required by the page, which are then retrieved from the cache, so that only one network transfer is required per page. The invention is compatible with previous operation, in particular by using the 'content negotiation' according to RFC 2295 or 'remote variant selection' according to RFC 2296.

The invention is described in more detail below on the basis of an exemplary embodiment and some variants.

An arrangement is sketched in FIG. 1, on the basis of which the sequence is to be described. The wave line 10 indicates a network to which a client below the wave line 10 and a server above the wave line 10 are connected. The network and the connections are preferably implemented using the Internet protocol HTTP.

In the client there is an HTML document 12 which contains a link, here '<a href=" testl .html"> link </a>'. By activating the link, a request is made to the HTTP process 14. The HTTP process includes a switch 16 with which it is decided whether the requested document "testl.html" is taken from the mass storage device 18 as before and sent back to the client, or the extension to be described is used. The display program ('browser') in the client that requested the page comprises a controller 22 for a buffer memory 24.

For example, the requested document "testl.html" is as follows:

<HTML> <HEAD> <TITLE> testl </ titlex / HEAD>

Image: <IMG SRC = imgl. pg ALT = "imgl">

Link: <A HREF=test2.html> test2 </a>

Script: <srcipt src = scriptl. jsx / script>

JAVA applet: <APPLET src = an_applet. java> </applet>

</ BODY> </ HTML>

In the event that the server process 14 only sends the requested document back as before, this is entered by the controller 22 into the buffer memory 24 as before and is then available to the display program as document 26. There are several references in document 26, namely the references'<img src = imgl. jpg>',<ahref=test2.html>"and<script src = scriptl. js>". Now the display program interprets the document "testl.html" and strikes precisely these references, whereupon the files “imgl.jpg”, “test2.html” and “scriptl.js” specified therein are successively requested by the server, stored in the cache 24 and then functionally inserted into the HTML text 26.

The invention changes the process as follows: An indicator in the request from "testl.html" informs the server process 14 that an archive can also be processed instead of the requested file. This indicator is presented in more detail below. If this indicator is set, the server process 14 checks whether there is a corresponding archive 20, here with the name 'testl .harc', and then sends this archive 20 back, symbolized by the switch 16. A corresponding entry in the header ('header') in accordance with the HTTP protocol, for example the (new) MIME type 'archive / harc' instead of 'text / html', indicates to the buffer memory process 22 that a instead of a single document Archive is transmitted. The buffer storage process 22 then breaks the archive down into its elements and stores these elements individually in the buffer memory 24, as indicated in FIG. 1. As in the example, include the file 'testl.html' in the archive. Since this is now in the buffer memory, it can be made available to the display program as before. This interprets the HTML text and determines that additional files are required. For this purpose, as always, it is first checked whether these are in the buffer memory. Since this is the case, these additional files 'imgl.jpg', 'test2.html' and 'scriptl.js' are taken from the buffer memory; communication with the server is no longer necessary.

For the indicator with which the client informs the server that an archive is welcome, either a new element can be defined in the HTTP header. However, content selection ('content negotiation') according to RFC 2295 or 'remote variant selection' according to RFC 2296 is preferred. The latter is mainly used to make different Requesting language variants of an HTML page is therefore not fully usable in order not to lose this ability. Better is the content selection that has been used so far that the server does not send the original file, but a compressed version. For this purpose, the formats known to the browser are listed in the header of the request; the server can then send one of these formats. A browser with a buffer memory according to the invention uses this header and adds an appropriate (MIME) type. A server that is not set up for this ignores this format and behaves as before. A server according to the invention only sends the archive format if the browser has declared it possible. This is one way of realizing the indicator listed above.

In another variant, the browser is set up in such a way that it first requests the file 'testl.harc' instead of the file 'testl.html' and, if the server shows this as not available, then requests the original 'testl.html'. The changed file type then represents the above-mentioned indicator.

In a development of the invention, the indicator permitting an archive is only set if the document is not yet in the buffer memory. In the event that it is still in the buffer memory but is no longer valid, an archive is then no longer permitted, since the other elements can still be valid.

Another development makes the requirement of an archive dependent on the fact that there are no or only a predetermined small number or only older documents of the same server in the buffer memory.

On the server side, one solution is that manually or automatically maintained lists, also by means of a data bank are implemented, which assign the file names of the archives pages. If the file name is found in one of the lists and the assigned archive exists, the archive is transferred instead of the file.

The server can also search for existing archives and the page in these archives and automatically transmit the archive in the event of a hit.

Another variant checks whether the subdirectory in which the requested file is or should be contains an archive. If this is the case, the archive is transferred instead of the file. Optionally, it can be checked beforehand whether the file is contained in the archive. In a further development, if no archive is available, it is created, saved and transmitted from all files of the subdirectory 'on the fly'. In this case, a positive or negative list of file types, in particular via their extensions, is preferably specified, for example, so that JAVA archives (.jar) are not included.

In an alternative application of the invention, the buffer memory of an intermediary referred to as a 'proxy' is used. A proxy server receives the request from the browser and in turn sends it to the server, receives the requested document and forwards it to the browser. On the one hand, a proxy server has a protective function in that the outbound requests are routed through a single, dedicated system. A proxy server such as 'SQID' or the corresponding Apache module is usually combined with a buffer memory in order to transmit requested pages as often as possible from the proxy via the expensive external connection without the external connection being loaded. The proxy server can therefore set the indicator, receive an archive, unpack it in the buffer memory and then use the fast and inexpensive internal network to make a large Efficiently supply a number of conventional browsers with parts of external HTML pages.

As a rule, and therefore preferably, the archive sent by the server contains the requested file, which is then processed further from the buffer memory.

In order to be robust against errors, the controller for the buffer memory should also be able to handle the case that the archive received does not contain the requested file. Since it is not generally possible to decide whether the content of the archive should be discarded for security reasons or whether it can still be set in the buffer memory, this selection is set via user options and may depend on whether simple HTTP or secure HTTPS is used as the protocol was used. Furthermore, either the requested file can immediately be treated as not available (error 404 in the HTTP protocol). Or a second request can preferably be made, in which the indicator that an archive is welcome is not set and the page is requested again individually.

On the one hand, after an archive has been determined which is assigned to the requested file, the server can check whether the requested file is present in the archive and only then send the archive, otherwise it can send the file itself. This solution is simple, manageable and robust against errors in the assignment of files and archives.

However, it is better if it is also checked whether the file in the archive is not only available but also up-to-date. If it is current and available, the archive is sent. If it is not up to date, either only the page is sent or the current page is temporarily or permanently replaced in the archive by the current version and then the archive is sent. If it does not exist, the archive can still be sent on the assumption that the control of the buffer memory, as described above, then requests the page again, but without an archive indicator. This applies to HTML pages, which are changed more often, but where the images etc. used in them are changed very rarely. In this version, an archive containing objects required by the page is still sent in front of the page, so to speak.

In a further development of this variant, the server sends two files upon request of a file; namely an archive without the file and then or before the file.

The indicator which indicates that an archive can be delivered instead of the requested page is useful for the invention, but not essential. For example, consider a closed network, as is often the case with self-service terminals. Then it can be assumed that all browsers are able to receive an archive instead of a requested file; explicit marking is no longer necessary. The same applies to the data supplied by the server: The MIME type in the header indicates that an archive is being sent. Alternatively, each file received can first be interpreted as an archive and only treated as a simple file if it is not a valid archive.

On the one hand, one of the formats known as 'are', 'zip', 'tar', 'epio', 'cab', '1ha' etc. can be used as the archive format, in which the files become a new file representing the archive be packed. Often a compression is used and the transfer is accelerated if the packed files are not already compressed, as is the case with the common image formats ^• gif, 'jpg' and 'png'. Another possibility with the HTTP (S) protocol is to encode the returned data as a multi-part message with separators in accordance with the MIME standard RFC-2046 ('multi-part message'). Here, a number of individual files are connected to a total stream by separators. The data type in the header is then 'multipart / mixed'. This variant has the advantage that the dynamic compilation in the server is particularly simple. The requested file is preferably sent as the first part. Then either a prepared file is added, which already has a

'multipart-message' and which can then be easily added (if necessary, by adjusting the limit separator

('boundary delimiter'). Or the files contained there are added individually according to a database entry or another list. This variant is functionally equivalent to a traditional archive and is therefore regarded as an archive format in the context of the invention.

The invention was described on the basis of HTML pages. It is equally applicable to other markup sites such as the successor XHTML, the XML extension, and other appropriate formats.

Claims

claims

1. Server for several files determined by addresses, in particular markup pages, with the features:

- Using the address contained in a request for a file, the server determines whether a) the file itself or b) an archive, which comprises several files, is sent back instead of the file.

2. Server according to claim 1, wherein the request comprises an archive indicator and an archive is only sent back if the indicator is present instead of the file.

3. Server according to claim 2, wherein the indicator is implemented by means of a content selection.

4. Server according to one of claims 1 to 3, wherein an associative list is used and,

- If this means that another file is assigned to the address of the requested file, this file is sent, and if several files are assigned to the requested file, these files are sent as an archive.

5. Server according to one of claims 1 to 3, wherein the requested file searches in existing archives and, if the requested file exists, sends back such an archive instead of the file.

6. Server according to one of claims 1 to 3, wherein the requested file is localized in a directory and instead of the file an archive of all files in the directory, formed according to predetermined selection criteria, is sent back.

7. Server according to one of the preceding claims, wherein the archive is designed as a multi-part message with separating lines.

8. Buffer memory with entries for addressed files, in particular markup pages, the buffer memory being an associative memory which has an index with the address of the buffered files and a memory with their contents, with the features: if a requested file is not present in the buffer memory or invalid, it is requested with its address from a server determined by the address, if the server sends an archive in which several files are packed instead of the addressed file, the archive is unpacked and the multiple files are added individually in stored in the buffer memory so that subsequent requests for these files from the buffer memory can be satisfied.

9. Browser for markup pages, comprising a buffer memory according to claim 8.