Development of new practical browser functions: session/view State replication and remote synchronization for single-page rich client applications

Research on the Development of New practical functions of browsers: session/view State replication and remote synchronization of single-page rich client applications

• 1. A simple Application Scenario
• 2. session/view status of a single page (rich client) Application
• 3. Status replication and remote Synchronization
• Web Cache changes in 4spa scenarios

A Simple Application Scenario

I successfully logged on to feedly using the Google oauth account on three machines. Unfortunately, the Google Account Login address was blocked by gFW, therefore, I cannot access my feedly on my new computer. Fortunately, feedly always caches my login creden( (I don't know if it is represented by a cookie ?), Therefore, if you refresh the page several times, you can still use feedly on the three old computers.

In fact, feedly is an example of a single page rich client application. It downloads an HTML file each time it is opened, and then HTML needs to load four compressed JS files, totaling 2 MB of data, if these four JS files are temporarily blocked by GFW, the page cannot be opened successfully. I am wondering why feedly does not make these four JS files into an infinite cache for each URL address. If you need a new JS version, add a version ID number to the four JS URLs, -- isn't that good?

Therefore, as a client browser, the first problem we need to solve is: how to restore the single-page application (SPA) that you have logged on to on another new computer) view/session Status ???

Session/view status of a single page (rich client) Application

First, let's consider what the so-called View session State actually refers?

1. View status: it contains the Web service response JSON data obtained through Ajax requests using JS, the DOM tree dynamically constructed, the scroll position of the frame, and so on.
2. The session Status SPA may need to be logged in and used (of course, if there is no privacy sensitive data, the Web SPA should not be logged in), and the session still uses cookies in the current browser architecture, however, theoretically, other "high-end" technologies may also be used:
   1. HTTP 1.1 etag
   2. Browser feature fingerprint
   3. HTML5 application Cache/Local Storage

Status replication and remote Synchronization

Consider only the simplest cookie, not the so-called view State replication recovery, then the simplest and most feasible method is to use a cloud-based Transit server (PS: currently, browser vendors only synchronize bookmarks and favorites. This is also the beginning of Taiyuan !), You can use the cookie Export and Import functions of the client.

This solution should be feasible. If you need an additional view rolling position or something, add a JS # hashtag code at most.

However, the disadvantage of this technical solution is that it is not general enough. Is there a higher-end solution?

Yes, but it is difficult to implement: the spa memory DOM tree is fully serialized and saved to the cloud server, and deserialization is performed as needed, there are many technical difficulties:

1. What kind of scheme is used for serialization? Is it serialized into HTML code? In this case, the special resourceloader logic needs to be customized for deserialization. Is it possible to achieve direct memory replication? Traditional Direct Memory replication requires that the CPU architecture be consistent, so as to avoid some problems related to the size end and other factors. How can we implement direct memory replication between heterogeneous CPUs?
2. The serialized data volume may be large. Is it possible to compress the data volume? UC/Opera's web page transcoding acceleration is actually such a case, but it mainly aims to reduce the data transmission volume of mobile users and adapt to the Internet needs of low-end mobile devices; is it possible to achieve partial serialization without affecting user availability (along with the delay loading technology )?

Okay, so much talk for the moment.

Web Cache changes in spa scenarios

In the traditional HTTP cache specification, cached resources are actually globally cached using URLs. This may be fine, but it is often felt that there are security vulnerabilities: I added the content of url B, C, and D through url a. When I request B, C, and D, set Referer TO A according to HTTP specifications, for B, C, and D servers, it is entirely possible to return different data based on the referer. Although theoretically, according to the original intention of HTTP, or rest specifications, this should not be done. In this case, if the access URL e loads the content of D and F, and D is referenced by A and E source pages, D may be an image or JS library hosted by CDN in actual use, of course, it may also be an embedded IFRAME advertisement.

In the spa scenario analyzed above, we can see that it is inappropriate for HTTP cache to use the URL as the global cache key, we should cache two copies of D for the two different source HTML documents A and E! For the moment, this new client cache scheme is called Web Cache. The trouble with this scheme is that the cache may be cascading and the existing browser does not handle this situation properly, this vulnerability causes a bunch of csrf security vulnerabilities.

Without csrf concerns, the Web cache may be a cascading, nested dependency layer-deep cache, but in the HTTP cache scheme, these subsequent dynamic content loading may all be marked as non-cacheable. Web advertisers actually require this, but I think they can take other better measures, to avoid swallowing excessive Internet traffic.

Browser vendors may be reluctant to develop such a local hierarchical clustering cache scheme that inspires the interests of advertisers, but end users may need this scheme...

Development of new practical browser functions: session/view State replication and remote synchronization for single-page rich client applications