Do you know Preserve log?

background

I was working on an internal company project recently. During the test, I found that no relevant data was brought after the interface request was completed. Then I opened the console to check whether it was an interface problem. I found that the interface reported the following exception. The status code was 200, but it was returned. The content cannot be displayed, and the console opened the Preserve log in advance. In theory, the request sent before should be recorded, but the response is indeed not visible. After investigation, it was found that there was a deviation in the understanding of Preserve log, which led to the next exploration.

Introduction to Preserve log

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

According to the introduction of Chrome's official documentation, if Preserve log is checked, all previous requests will be retained when cross-page loading requests. The purpose is to facilitate developers to troubleshoot some cross-site requests that are interface issues, such as data comparison. But what the official website does not say is that if you want to see the returned Response, you must click to view the interface in advance before the page jumps, and then you can see the information returned by the previous interface after the jump. For those interfaces that have not been clicked In the next page, the returned results cannot be viewed. The information seen by Response is similar to the above picture, and there will be a common error "Failed to load response data". Is that true for all browsers? Or is it just the Chrome family? Next, an analysis is made on the compatibility of Preserve log.

Preserve log compatibility

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

1. Choose a page that can jump from site A to site B
2. Open the console and check the Preserve log option
3. Refresh the page, find any request for page A to open, and do not click for other requests
4. Click the link from the A website to the B website, and check the previous request data of the A website on the B website
   The experimental results are as follows:

Chrome

In Chrome, the results of the experiment are the same as what we have seen before. Only clicked requests are reserved, and responses that are not clicked are not displayed.

Safari

In Safari, the performance of Preserve log is the same as Chrome. Only the interface after clicking will retain the Response. The unclicked interface will display "An error occurred while trying to load the resource". The corresponding result cannot be viewed. One advantage of Safari is , After jumping to website B, the requests of website A in the console are grayed out, which will facilitate observation and operation.

Firefox

In Firefox, if Persist Logs is checked, the request will be fully retained. On the next page, you can see the complete request and returned information of the previous page, indicating that Firefox is not restricted.

Why does the Preserve log not keep the request log intact?

Through the above analysis, we will find that different browsers handle the retained logs differently. This approach to Chrome has also caused extensive discussion on issues, and it is still a long-standing issue. In summary, opinions can be divided into two factions.

Opponent:

• Errors in NetWork can easily make others mistakenly believe that the error is on the server side, causing misunderstandings
• If the redirect happens very quickly, it is difficult for users to click on the link, so you have to use third-party tools to help
• Preserve log is ambiguous, it is obviously to keep the log, but the actual result does not keep the log as complete as Charles and other tools

Approvers (chromium developers):

• This is the result of "low overhead", Response will not be passed to DevTools unless the user wants to view and click on it, in order to avoid distortion of the measurement results
• If all Responses are kept in DevTools, a lot of unnecessary content will be added. If the user clicks on a lot of cross-site links, the consequences are unimaginable
• This is the best compromise solution, taking into account both ease of use and flexibility

The two opinions have their own reasons, but I think Chrome should release this permission to developers, because DevTools is originally for developers, and Preserve log does not solve the problem of developers’ cross-site requests that need to view the original link. The appeal, the original intention of keeping logs should be to keep all Request and Response information, and should not be castrated version, it should be up to the developer to control whether to enable this option and assume the corresponding results. Otherwise, sometimes you have to capture packages through third-party tools or, as mentioned in the issue, you need to do processing at the code level, which undoubtedly complicates an originally simple function.

The pace of improvement of browser vendors

There are also some Chromium feedbacks in the issue. I originally thought that this requirement was unnecessary and the priority was relatively low. It was closed in 17 years due to priority and resource issues, but it seems to have restarted recently, and the status has become Open. I look forward to it. Later versions can improve this problem.

Summarize

The above is a brief introduction to Preserve log. If you really encounter the above problems during development, the following solutions can be considered:

1. Use Firefox browser (it seems that few people use it at the moment)
2. As mentioned in the issue, debugging is done by arranging points in the code, "window.onunload = function() {debugger;}", but it is not very convenient in actual application
3. Use capture tools such as Charles to capture packets

Reference documents

• https://developer.chrome.com/docs/devtools/network/reference/
• https://stackoverflow.com/questions/38924798/chrome-dev-tools-fails-to-show-response-even-the-content-returned-has-header-con
• https://bugs.chromium.org/p/chromium/issues/detail?id=141129

Author: ES2049 / Luoshen

The article can be reprinted at will, but please keep this link to the original text.
You are very welcome to join ES2049 Studio if you are passionate. Please send your resume to [e-mail].