background

Recently, I was working on an internal project of the company. During the test, I found that there was no relevant data after the interface request was completed, and then I opened the console to check whether there was an interface problem. I found that the interface reported the following abnormality, the status code was 200, but the returned content could not be displayed. Theoretically, the request sent earlier should have been logged, but the Response was not seen. After investigation, it was found that there was a misunderstanding of the Preserve log, which led to the subsequent exploration.

Preserve the log profile

To save requests across page loads, check the Preserve log checkbox on the Network panel. DevTools saves all requests until you disable Preserve log.

Chrome’s Preserve Log, if enabled, will retain all previous requests when loading a cross-page request. This log is designed to help developers solve problems with cross-site requests, such as data comparison. However, what is not written in the official website is that if you want to see the returned Response, you must click and view the interface in advance before the page jumps, so that you can see the information returned by the previous interface after the page jumps. For those interfaces that have not been clicked, you cannot see the returned result on the next page. Response The information is similar to that in the picture, and there is a common error “Failed to load Response data”. Is this true of all browsers? Or is it just Chrome? An analysis of the compatibility of the Preserve Log follows.

Preserve Log Compatibility

We selected three browsers as samples: Chrome, Safari and Firefox. The verification steps are as follows:

  1. Select A page that jumps from site A to site B
  2. Open the console and check the Preserve Log option
  3. Refresh the page, find any page A request to open, other requests do not click
  4. Click the link of A website to jump to B website, and check the request data of A website before B website, and the experimental results are as follows:

Chrome

In Chrome, the experiment results are the same as we saw before, reserving only clicked requests and showing no Response for unclicked requests.

Safari

In Safari, the Preserve log behaves exactly as in Chrome. Only the interface that is clicked on retains a Response, while the interface that is not clicked displays an error while trying to load a resource, and the corresponding result cannot be viewed. The request of website A in the console is dimmed, which will facilitate observation and operation.

Firefox

In Firefox, if you select Persist Logs, the request is kept intact, and the complete request and return information from the previous page are displayed on the next page, indicating that Firefox is not restricted.

Why does the Preserve Log not completely retain the request log

According to the above analysis, different browsers treat log retention differently. Chrome’s processing method has also triggered a wide discussion on issue, which has a long history. Generally, there are two sides of the issue.

Opponents:

  • NetWork errors can easily lead others to mistakenly believe that errors occur on the server, resulting in misunderstanding
  • If the redirection happens very quickly, it will be difficult for the user to click the link, so third-party tools will have to help
  • The Preserve log is ambiguous, but the actual result is not as complete a Preserve log as Charles and other tools

Endorser (Chromium Developer) :

  • This is the result of “low overhead”, and the Response is not passed to DevTools unless the user wants to view and click on it, in order to avoid distorting the measurements
  • If all Response is kept in DevTools, a lot of unnecessary content will be added. If users click a lot of cross-site links, the consequences will be unimaginable
  • This is the best compromise between ease of use and flexibility

Both sides have their reasons, but I think Chrome should give DevTools to developers because DevTools is for developers, and the Preserve Log doesn’t address cross-site requests that developers need to see the original link. The intention of keeping a log should be to keep all requests and responses, not to make an emasculated version, and it should be up to the developer to control whether or not to enable this option and take the consequences accordingly. Otherwise, sometimes we have to use third-party tools to capture packages or, as mentioned in the issue, we need to deal with them at the code level, which undoubtedly complicates an originally simple function.

Browser vendors’ pace of improvement

There is also some Chromium feedback in the issue. I thought it was unnecessary to do this requirement and the priority was low. In 2017, it was closed due to priority and resource problems, but it seems to have been restarted recently and the status has changed to Open.

conclusion

The above is a brief introduction to the Preserve Log. If you do encounter the above problems during development, you can consider the following solutions:

  1. Use Firefox (not many people seem to use it at the moment)
  2. As stated in issue, debugging is done by clicking in the code, “window.onunload = function() {debugger; } “, but the practical application is not very convenient
  3. Use Charles to capture packets

Reference documentation

  • Developer.chrome.com/docs/devtoo…
  • Stackoverflow.com/questions/3…
  • Bugs.chromium.org/p/chromium/…

Author: ES2049 / Luo Shen

The article can be reproduced at will, but please keep this link to the original text.

You are welcome to join ES2049 Studio. Please send your resume to [email protected].