WO2022167482A1

WO2022167482A1 - Identification of compressed net resources

Info

Publication number: WO2022167482A1
Application number: PCT/EP2022/052479
Authority: WO
Inventors: Carl HASSELSKOG
Original assignee: Degoo Backup Ab
Priority date: 2021-02-03
Filing date: 2022-02-02
Publication date: 2022-08-11
Also published as: SE2150128A1; EP4288877A1

Abstract

Method, device, and computer program product for providing a http resource to a client device. A first http request identifying a http resource at a resource server is received from a client. A request for the http resource is sent to the resource server. A first dataset is received in response to the request and is saved and used to create a first hash. The first dataset and the first hash are sent to the client. The first hash and a second http request for the same http resource are received from the client. A second request for the same or a similar http resource to is sent the resource server. A second dataset is received in response to the second request and is saved and used to create a second hash. The first and second hashes are compared. If they are identical, the client is instructed to use the first dataset stored in the client to provide the http resource to a user.

Description

Identification of compressed net resources

Field of the invention

This invention relates to methods and systems for providing http resources, such as web pages.

Typically, http resources, such as web pages, are provided by a server to a client after the server receives a http request from the client.

Data traffic over the Internet is growing. For example, today's web pages require much more bandwidth than web pages twenty years ago. A problem is that network capacity in some areas is limited, which results in a poor experience to users, as fetching web pages or other http resources takes too long time. Data traffic may also be expensive for users, and users of smart phones frequently have a limited monthly data traffic allowance.

Summary of invention

In a fist aspect of the invention there is provided a method at a compression server for providing a http resource to a client, comprising the steps of: a) receiving a first http request for a http resource from a client device, the http request comprising information that identifies a http resource at a resource server, b) sending a request for the http resource to the resource server, c) receiving, from the resource server, a first dataset for the http resource in response to the request, d) saving the first dataset and using the first dataset to create a first hash, e) sending the first dataset and the first hash to the client device, f) receiving, from the client, the first hash and a second http request for the same http resource, g) sending a second request for the same http resource or a similar http resource to the resource server, h) receiving, from the resource server, a second dataset for the http resource in response to the second request, i) saving the second dataset and using the second dataset to create a second hash, j) comparing the first hash and the second hash, and k) in response to determining that the first and second hashes are identical, providing a signal to the client device instructing the client device to use the first dataset stored in the client device set to provide the http resource to a user of the device.

The method may comprise the additional step: l) in response to determining that the first and second hashes are different, compressing the second dataset and providing the compressed second dataset to the client device.

The second dataset comprises text preferably comprises text. The second dataset is compressed using a difference compression algorithm, preferably using dictionary-based compression.

The compression server and the client device may independently create a dictionary for compression based on identical http resource data stored by the compression server and the client device respectively, and the dictionary may be used by the compression server to compress the file and used by the client device to decompress the file. The client device and the compression server may each store a plurality of datasets for providing the http resource, and the client device provides the hash values for the plurality of datasets as part of providing the first hash, and the plurality of datasets is used to compress the second dataset.

The dictionary may be based on at least one dataset that is likely to be similar to the second dataset.

A compression server configured to conduct the method according to the first aspect of the invention is also provided. Client software, for example a browser, is also provided for conducting the client-side steps of the method of the first aspect of the invention.

A computer program product is also provided for providing a http resource to a client device, in accordance with the method of the first aspect of the invention.

There is also provided a method for providing a http resource comprising the steps of a) a client device sending a first http request for a http resource to a compression server, the http request comprising information that identifies a http resource at a resource server, and where the compression server comprises compression software for compressing data for a http resource, b) the compression server sending a request for the http resource to the resource server defined by the http request, and the resource server sending a first data set for the http resource to the compression server, c) the compression server saving the first data set and using the first data set to make a first hash, and the compression server sending the first data set and the first hash to the client device, d) the client device receiving the first data set and the first hash and storing them, e) the client device sending a second http request to the compression server for the same http resource, and providing the first hash to the compression server, f) the compression server receiving the second request from the client device and sending a second request for the same http resource or a similar http resource to the resource server, and the resource server sending a second data set for the http resource to the compression server, g) the compression server saving the second data set and using the second data set to make a second hash, h) the compression server comparing the first hash and the second hash and if they are the same, providing a signal to the client device that causes the client device to use the first data set stored in the client device set to provide the http resource to a user of the device.

In a second aspect of the invention there is provided a method at a compression server for providing a http resource to a client comprising the steps of: a) receiving a http request for a http resource from a client device, the http request comprising information that identifies a http resource at a resource server, b) sending a request for the http resource to the resource server, c) receiving, from the resource server, a dataset for the http resource in response to the request, d) compressing the dataset, using compression software, to generate compressed data, e) providing the compressed data to the client device, to use in providing the http resource to a user of the client device.

The dataset may preferably comprise or be a text file, for example a file selected from a html file, a java script file and CSS file. The dataset is preferably compressed using a difference compression algorithm, preferably dictionary-based compression.

Hence in a preferred embodiment the dataset comprises a text file and where dictionary- based compression is used.

In a preferred embodiment the compression server and the client device independently create a dictionary for compression based on identical http resource data stored by the compression server and the client device respectively, and where the compression server uses the dictionary to compress the file and used by the client device to decompress the file.

The dictionary may be based on at least one dataset that is likely to be similar to the dataset of the http resource that is requested. When the requested http resource is identified by an URL, the dataset used for creating the dictionary may be selected by comparing the URL of the requested http resource with URL:s of other http resources for which the client device has stored dataset, and selecting a dataset with an URL that is similar to the URL of the requested http resource.

Datasets with similar URLs are more likely to have similar content and hence may are more likely to produce a useful dictionary, i.e., a dictionary that comprises abbreviations for many phrases in the dataset to be compressed.

Similarity may be determined by grouping URLs into groups according to predetermined criteria, where the groups have a predetermined ranking.

The compression server and the client device may use a cryptographically unique identifier, such as hash, of the http resource data to identify the http resource data used for creating the dictionary. The hash may be included in the http request from the client device of step a).

The dictionary may be based on a plurality of http resource datasets. A compression server configured to conduct the method according to the second aspect of the invention is also provided.

Client software, for example a browser, is also provided for conducting the client-side steps of the method of the second aspect of the invention.

A computer program product is also provided for providing a http resource to a client device, in accordance with the method of the second aspect of the invention.

The accompanying drawings form a part of the specification and schematically illustrate preferred embodiments of the invention and serve to illustrate the principles of the invention.

Fig. 1 is a schematic overview of a system, in accordance with one embodiment.

Fig. 2 is a schematic drawing of client device where both software and hardware components are shown, in accordance with one embodiment.

Fig. 3 is a schematic overview of a server, in accordance with one embodiment.

Fig. 4 and 5 are flowchart showing methods, in accordance with one embodiment.

Fig. 6 is a schematic drawing of hardware, in accordance with one embodiment.

Detailed

System 1 comprises a client device 2 and a compression server 3. Resource server 4 is a server that provides http resources such as web pages, RSS feeds, video, or the like. Hence resource sever 4 may be a web server. Resource server 4 may or may not be a part of system 1, but typically system 1 does not comprise resource server 4 but is configured to communicate with resource server 4. Communication between client device 2 and compression server 3 as well as between compression server 3 and resource server 4 is done over the internet as is known in the art.

The client device 2 may be any type of client device 2 such as a smart phone, a laptop, or a tablet computer, such as for example an iPhone or an Android smart phone. It is preferred that the client device 2 can provide http resources to a user, for example by displaying content on a display 5 or play sounds on a speaker 6, or to headphones. It is preferred that the client device 2 can display web pages. The client device 2 mayforthis purpose have installed in its memory 7 a client software 8, for example a browser 8 for displaying web pages, described in more detail below. Client software 8 (or browser 8) does not have to be a web browser but will be referred to as "browser 8" herein. Client software 8 may hence by arranged to send http requests, receive data for http resources from a server, and provide http resources to a user of a client device 2.

Browser 8 may be software adapted to display web pages, for example using html, CSS, or JavaScript. The browser 8 is adapted to receive input from a user, for example using a keyboard or touch display or speech recognition whereby a user can enter commands for fetching a http request. For example, the user may type the address of a web page into the browser 8. The browser 8 then sends a request for the http resource to the compression server 3.

A http resource herein may be any type of http resource, such as a web page, a video, a sound file, or an RSS feed. In a preferred embodiment the data that enables the client device to provide the http resource to a user comprises text such as a html file or a java script file. Data for the http resources is stored by the resource server 4. The data may be in a file format. Each http resource is identified with a unique identifier which may be an URL (Uniform Resource Locator) or an IP address, for example the web address of a web page, such as for example https://edition.cnn.com/. Social media such as Facebook pages or similar may also be provided as http resources. Of course, a web page may comprise text as well as images, video, and sound, but preferably the data comprises at least some text. According to the prior art, a client device 2 obtains data for the http resource by sending a http request to the resource server 4, which then provides the http resource to the client device 2.

However, according to one embodiment of the invention, the client device 2 provides the http request to the compression server 3 instead. Hence the browser 8 is configured to provide a http request to compression server 3. In a preferred embodiment the http resource can change over time without changing its unique identifier. The http resource may for example be a dynamic web page, or a feed for a social media platform.

The browser 8 may, however, in case it cannot reach compression server 3, for example due to some technical fault, send a http request directly to resource server 4 instead.

Client device 2 may comprise decompression software 9 for decompressing data that has been received from the compression server 3. Client device 2 may comprise cache 10 for storing data for http resources, and a database 11 for keeping track of various versions of http resources, for example by storing a hash and relating a hashed to the cashed data and the http resources.

Compression server 3 has compression software 12 for compressing various types of data. Different types of data such as text and video are preferably compressed using different algorithms. For text, a non-lossy compression algorithm is preferred. It is preferred that the type of compression used is diff-based compression, in particular dictionary-based compression. This is particularly suited when the data is text-based, such as for example text files (html or JavaScript).

Dictionary-based compression may be based on a common dictionary that is independently constructed by the compression server 3 and the client device 2 using a text dataset, such as a text file, as a starting point. Provided that the same algorithm is used by the client device 2 and the compression server, the client device 2 and the compression server 3 will arrive at the same dictionary in a deterministic fashion. Dictionary based compression as such is known and may also referred to as dictionary coder in dictionary-based compression a known file that is shared by both sender and receiver is used to create a dictionary. The dictionary comprises a list of phrases and abbreviations. A second dataset is compressed by applying the dictionary to the second dataset and replacing phrases with abbreviations. Text in the second dataset that cannot be found in the dictionary is provided in non-compressed form.

The compression server 3 also comprises browser reply software 13 for handling http requests from the browser 8 of client device 2.

Compression server 3 may also comprise hashing software 14 adapted to apply a cryptographic hash function to data to provide a hash or a different type of cryptographically unambiguous identifier.

The term "cryptographically unambiguous identifier" (CUI) refers to a second set of data (the digest) derived from a first set of data, where the second set of data is deterministically determined by the first set of data, and where the first set typically cannot be determined from the second set of data. Thus, even a minor change of the first set of data results in a substantial change in the second set of data. Preferably the second set of data is much smaller than the first set of data (requires much less storage space). Preferably the second set of data has a fixed size. Examples of cryptographically unambiguous identifiers are: checksum digits and a hash, where a hash is preferred. Applying a hash algorithm to data results in the output of a fixed size bit string. One example of a frequently used hash algorithm is SHA 256. Other hash functions are SHA-1 and SHA 512. Such a CUI may serve as a "fingerprint" for the first set of data.

Compression server 3 may also comprise a cache 15 for storing datasets for http resources (resource dataset), and a database 16 that stores CUI: s for various datasets for http resources or other means for keeping track of different versions of http resources, such as time stamps. In the database 16 a hash (or other CUI) is associated with one and only one dataset for a http resource. Hence the hash (or other CUI) may be used to identify the dataset.

Fig. 4 is a flowchart that shows a method. In step 100 a client device 2 sends a http request for a http resource to a compression server 3, where the http request comprises information that identifies a http resource at a resource server 4. Step 100 may for example be initiated by a user of client device 2 specifying an URL address in some manner. Optionally the client device 2 in this step provides information to the compression server 3 in the http request that specifies which datasets for other http resources that the client device has stored in its memory, in particular previous versions of the requested http resource or datasets for http resources that are similar, or likely to be similar, but not identical, to the dataset for the requested http resource. The use of hash (or other CUI) for tracking datasets for this purpose is described below with reference to Fig. 5.

In general, browser reply software 13 of compression server 3 handles request from client device 2 and provides messages from compression server 3 to client device 2.

In step 101 the compression server 3 sends a request for the http resource to the resource server 4 defined by http request, and the resource server 4 sends a dataset for the http resource to the compression server 3.

In step 102 the compression server 3 receives the dataset and uses compression software 12 to compress the dataset to obtain compressed data.

In step 103 the compression server 3 provides the compressed data to the client device 2.

In step 104 the client device 2 receives the compressed data and uses the compressed data to provide the http resource to a user of the device 2. For example, when the http resource is a web page the web page is displayed to the user, for example on the display 5 of the client device 2. When the http resource is a video, the video is played by the client device 2. When the http resource is sound, for example a podcast, the podcast is played by the client device for example using speaker 6.

The data preferably comprises text, for example a html file or a JavaScript file and compression is preferably done using a difference compression algorithm. In particular, dictionarybased compression may be used. As is known in the art the compressed data is, when dictionary-based compression is used, provided as information about where coded phrases appear and typically some non-decompressed data (phrases that are not present in the dictionary).

When dictionary-based compression is used, the compression server 3 and the client device

2 preferably independently create a dictionary for compression based on identical http resource datasets stored by the compression server 3 and the client device 2 respectively, and where the dictionary is used by the compression server 3 to compress the data and used by the client device 2 to decompress the data. For example, the dictionary may be based on a data that the compression server 3 has access to, and that the compression server 3 knows that the client device 2 has access to, for example a text file, such as html or JavaScript code for providing a web page. Different versions of the web page may be identified using a hash (or other CUI) as described herein. For example, and with reference to Fig. 5 the compression server 3 receives the hash values from the client device 2 and compares the hash values of the message from the client device 2 to hash values in the database 16. The compression server 3 then bases the dictionary on datasets that are present at both compression server

3 and client device 2. Timestamps may also be used for identifying different versions of http resources.

In a preferred embodiment the compressed data is provided from the compression server 3 with data that identifies the data, for example text data, used for building the dictionary, in particular http resource dataset that is used for building the dictionary. In a preferred embodiment the dictionary is based on a plurality of http resource datasets. An advantage of basing the compression of a plurality of dataset is that compression can be made more efficiently.

Compression may be based not only on datasets for the http resource but also on datasets for similar http resources in particular similar text files. This has the advantage of providing even more data for building the dictionary.

For example, when the http resource is identified by an URL, compression may be based on datasets for http resources with similar, but not identical, URLs. Hence the similar dataset may be identified by comparing the URL of the requested http resource with the URL of http resources that are stored by the compression server 3 and which the compression server 3 knows that the client device 2 has stored in its cache 10. The client device 2 may provide the compression server 3 with the CUI (hash) of datasets client device 2 determines likely is similar to the dataset that is to be compressed. Hence, client device 2 may comprise logic for determining the similarity between URLs for datasets and select datasets with URLs that are similar to the requested http resource, for creating the dictionary.

Similarity may be determined by grouping URLs into groups according to predetermined criteria, where the groups have a predetermined ranking. For example, the compression server may 1) first look for datasets for http resources with URLs that are identical to the requested web address, 2) then look for URLs that have the same domain address and path, but possibly a different query string 3) then look for URLs in the same domain but otherwise different, 4) then for URL:s that have the same path, but in different domains. The fourth option may be useful to reuse files that are used across multiple domains such as advertising scripts. A request for such a script is typically made as a sub request.

Other groups and rankings may off course be used to determined similarity.

The extend on similarity between URL:s may be determined using suitable techniques such determining a Levenshtein distance between two URLs, for example. The system 1 or the browser 8 may be configured to provide updated data for http resources under certain conditions, in particular data for http resources for http resources that a user frequently uses.

The operating system of client device 2 may for example detect a cue from the hardware of client device 2, or from a part of the operating system itself, of client device 2 to trigger prefetching of data for a predetermined http resource. The cue may be provided to the browser 8 from the operation system of the client device 2. The cue may be a cue that indicates that the client device is currently not being used by a user. The cue may be a cue selected from: the client device is connected to Wi-Fi, the battery of the client device 2 is being charged, the display 5 of the client device 2 is switched off, the client device 2 is not playing sound, a certain time of day, for example during night-time, such as between 1 Am and 5AM. It may be useful for example if client device updates its cache 10 with http resource dataset for cnn.com at night-time if a user frequently visits cnn.com in the morning, because then the web page will be displayed faster to the user.

Fig. 5 shows a method wherein a client device 2 and compression server 3 used hashes (or other CUI:s) to identify versions of http resources such as web pages. The method is also used as identities for datasets that are likely to be similar to datasets for requested http resources.

In step 200 a client device 2 sends a http request for a http resource to a compression server 3. The http request comprises information that identifies a http resource at a resource server 4, for example, a web address.

In step 201 the compression server 3 sends a request for the http resource to the resource server 4 defined by the http request, and the resource server 4 sends a dataset (first dataset) for the http resource to the compression server 3. In step 202 the compression server 3 saves the first dataset in the cache 15. The compression server 3 then uses the hashing software 14 and the first dataset to make hash (digest) (first hash) of the first dataset. The first hash is stored in database 16 of the compression server 3, where it is associated with the first dataset. The compression server 3 then sends the first dataset and optionally the first hash to the client device 2. The first dataset may be provided non-compressed to the client device 2 but may also be slightly compressed, for example, using Brotli compression.

In step 203 the client device 2 receives the first dataset and optionally the first hash and stores them in memory 7. The first dataset is stored in the cache 10 of the memory 7. The first hash is stored in the database 11 of the client device 2.

The client device 2 may then use the first dataset to provide the http resource to a user of the client device 2. The client device may for example display a web page that is defined by the first dataset.

In step 204 the client device 2 sends a second http request for the same http resource to the compression server 3. For example, the second http request comprises the same web address as the first http request. This may for example be caused by the user revisiting the same web page using browser 8. Dynamic http resources such as dynamic web pages may be updated automatically, without the users triggering a http request. The client device 2 provides the first hash together with the second request, for example in the http request message.

In step 205 the compression server 3 receives the second request from the client device 2.

The compression server 3 then, in step 206, optionally sends a second request for the same http resource to the resource server 4, and the resource server 4 sends a second dataset for the http resource to the compression server 3. The compression server 3 saves the second dataset in the cache 15. The compression server 3 uses the second dataset to make a second hash. The hash is stored in the database 16 of the compression server. Alternatively, the compression server 3 has already, before receiving the second request from the client device 2, asked the resource server 4 for an update. The compression server 3 has then suitable also made the second hash when receiving such an update from the resource server 4.

In step 207, the compression server 3 compares the first hash and the second hash. Logic for this may be comprised in browser reply software 13 or in database 16, for example. If the first hash and the second hash are the same, the first dataset and the second dataset are identical. This means that the http resource has not been changed between the requests (first and second http requests from the client device 2). Hence, client device 2 can use the first dataset, which has been cached by the client device 2, to provide the http resource to the user of the client device 2. Compression server 3, therefore, in step 208 after concluding that first hash and second hash is identical, provides a signal to the client device 2 that causes the client device 2 to use the first dataset stored in the cache 10 of client device 2 to provide the http resource to a user of the client device 2. For example, the client device 2 may use the first dataset for displaying a web page on the display 5 of the client device 2.

Hence the hash value (digest) (or other type of CUI) is used by the system 1 to keep track of which version of a http resource that is cached by the client device 2.

If the first and second hash are not the same, the compression server 3, may optionally in step 209 provide the second dataset to the client device 2. This is preferably done in a compressed form as is described above with reference to Fig. 4. Hence when concluding that the first and second hash are not the same, the compression server 3 may proceed to compress the second dataset and provide the compressed data to the client device 2. The client device 2 may then decompress the second dataset and use it to provide the http resource to the user of the client device 2. As discussed herein it is preferred that the compressed data is a text file. It is also preferred that a difference compression algorithm is used, such as dictionary-based compression. Hence the compression of the second dataset may be based on a dictionary based on the first dataset. The compression server 3, which knows that client device 2 has first dataset (because client device has sent first hash) uses the first data to construct a dictionary and uses the dictionary to compress the second dataset. The compressed file is provided from the compression server 3 including information about what data has been used to compress the file, i.e., the first hash. The client device 2 receives the compressed data and the hash and uses the first dataset (stored in memory 7) to construct an identical dictionary, to decompress the second dataset. Because the dictionary is built in a deterministic way, it will be identical at client device 2 and compression server 3 although build interpedently by the compression server 3 and the client device 2. Hence hashing may be used to exchange information about what data the encryption is based on.

In one embodiment, the client device 2 and the compression server 3 has stored a plurality of datasets for providing the http resource and the client device 2 provides the hash values for the plurality of datasets in step 204 and the plurality of datasets is used to compress the second dataset in step 209. Hence the client device 2 attaches a plurality of hashes to the http request, saying "I have these previous versions of the http resource" to the compression server 3. An advantage of basing the compression of a plurality of dataset is that compression can be made more efficiently.

Compression may be based not only on datasets for the http resource but also on datasets that are likely to be similar, in particular similar text files, such as similar web pages, as described above.

It is understood that the present methods and system is computer-implemented, using digital computer equipment. The various embodiments and components described herein such as client device 2, compression server 3 and resource server 4 and communication between these components uses digital computer technology for storing and handling digital information and signals as well as suitable hardware and software, including for example suitable digital processors, digital memories, input means, output means, buses, and communications interfaces. A user may be able to make input using for example a keyboard, a mouse, or a touch screen. Output may be provided on for example a display 5.

The various components, such as client device 2 and compression server 3 may each have an operating system. With reference to Fig. 6 each of client device 2, compression server 3, and resource server 4, may comprise control circuitry comprising a memory 80, a processor 81, a bus 82 and a communication interface 83.

Compression server 3 or resource server 4 may be one physical server or may be a virtual server. Function of compression server 3 or resource server 4 may hence be distributed across several physical entities.

The methods herein can be implemented with any suitable combination of software and hardware. Any suitable programming language may be used for the software units and methods described. Data communication in system 1 and between system 1 and resource server 4 may be implemented using suitable networking technologies and protocols, inducing cellular communication such as 3G, 4G and 5G, LoRa, Wi-Fi or Bluetooth, or Ethernet. Data communication can be wireless, or wire bound. Information may be exchanged over a wide area net such as internet. Data communication in system 1 may be encrypted.

Communication in system 1 between client device 2, compression server 3 and resource server may be conducted using any suitable schedule. Typically, a reply to a http request is sent immediately. However, lazy loading may be used for saving data. Lazy loading means that the interactions of a user with a web page trigger loading of web resources such as for example an image. For example, advertisements may be loaded as a user scrolls towards the site where an advertisement is to be inserted.

In certain embodiments, the CUI may be calculated by the client device independently from the compression server. It is realized that everything which has been described in connection to one embodiment is fully applicable to other embodiments, as compatible. Hence, the invention is not limited to the described embodiments, but can be varied within the scope of the enclosed claims. While the invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention. The invention is generally defined by the claims.

Claims

1. At a compression server, a method for providing a http resource to a client, comprising the steps of: a) receiving a first http request for a http resource from a client device, the http request comprising information that identifies a http resource at a resource server, b) sending a request for the http resource to the resource server, c) receiving, from the resource server, a first dataset for the http resource in response to the request, d) saving the first dataset and using the first dataset to create a first hash, e) sending the first dataset and the first hash to the client device, f) receiving, from the client, the first hash and a second http request for the same http resource, g) sending a second request for the same http resource or a similar http resource to the resource server, h) receiving, from the resource server, a second dataset for the http resource in response to the second request, i) saving the second dataset and using the second dataset to create a second hash, j) comparing the first hash and the second hash, and k) in response to determining that the first and second hashes are identical, providing a signal to the client device instructing the client device to use the first dataset stored in the client device set to provide the http resource to a user of the device.

2. The method of claim 1, further comprising:

I) in response to determining that the first and second hashes are different, com- pressing the second dataset and providing the compressed second dataset to the client device. The method of claim 2 where the second dataset comprises text. The method of any one of claims 1 to 3 where the second dataset is compressed using a difference compression algorithm. The method of claim 4 where the difference compression algorithm is dictionarybased compression. The method of claim 5, further comprising: creating a dictionary for compression based on http resource data stored by the compression server, wherein the dictionary is used by the compression server in compressing the second dataset, and wherein an independently created corresponding dictionary from identical http resource data is used by the client device in decompressing the compressed second dataset. The method of claim 6 wherein: the client device and the compression server each stores a plurality of datasets for providing the http resource, receiving the first hash from the client device includes receiving the hash values for the plurality of datasets, and using the received hash values in compressing the second dataset. The method of claim 6 or 7 where the dictionary is based on at least one dataset that is likely to be similar to the second dataset. A compression server, comprising: a memory, and a processor, wherein the memory contains instructions that when executed by the processor performs a method comprising the following steps: a) receiving a first http request for a http resource from a client device, the http request comprising information that identifies a http resource at a resource server, b) sending a request for the http resource to the resource server, c) receiving, from the resource server, a first dataset for the http resource in response to the request, d) saving the first dataset and using the first dataset to create a first hash, e) sending the first dataset and the first hash to the client device, f) receiving, from the client, the first hash and a second http request for the same http resource, g) sending a second request for the same http resource or a similar http resource to the resource server, h) receiving, from the resource server, a second dataset for the http resource in response to the second request, i) saving the second dataset and using the second dataset to create a second hash, j) comparing the first hash and the second hash, and k) in response to determining that the first and second hashes are identical, providing a signal to the client device instructing the client device to use the first dataset stored in the client device set to provide the http resource to a user of the client device. A computer program product for providing a http resource to a client, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, wherein the computer readable storage medium is not a transitory signal per se, the program instructions being executable by a processor to perform a method comprising: a. receiving a first http request for a http resource from a client device, the http request comprising information that identifies a http resource at a resource server, b. sending a request for the http resource to the resource server, 22 c. receiving, from the resource server, a first dataset for the http resource in response to the request, d. saving the first dataset and using the first dataset to create a first hash, e. sending the first dataset and the first hash to the client device, f. receiving, from the client, the first hash and a second http request for the same http resource, g. sending a second request for the same http resource or a similar http resource to the resource server, h. receiving, from the resource server, a second dataset for the http resource in response to the second request, i. saving the second dataset and using the second dataset to create a second hash, j. comparing the first hash and the second hash, and k. in response to determining that the first and second hashes are identical, providing a signal to the client device instructing the client device to use the first dataset stored in the client device set to provide the http resource to a user of the client device.