Issue metadata
Sign in to add a comment
|
Wrong value of "Size" in Chrome DevTools > Network
Reported by
jbbme...@gmail.com,
Nov 15 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: See here: https://developers.google.com/web/tools/chrome-devtools/network-performance/reference > They are saying: "Size. The combined size of the response headers plus the response body, as delivered by the server." Or this reference is incorrect and need to be corrected, or it's a bug in Chrome. I have this file: caching-1.html <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Test</title> </head> <body> Test caching behavior ... </body> </html> The size of the file itself is: 183 B. What i did: - Open Chrome - Type in address bar: http://www.example.com/caching-1.html - To be sure, press: CONTROL F5 The response headers are: HTTP/1.1 200 OK Date: Wed, 15 Nov 2017 17:52:02 GMT Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16 Last-Modified: Wed, 15 Nov 2017 17:18:08 GMT Accept-Ranges: bytes Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 132 Keep-Alive: timeout=1, max=100 Connection: Keep-Alive Content-Type: text/html Chrome DevTools is showing "Size": 528 B Now i did this: - In Chrome in the existing window from previous test, press: CONTROL N (opening new window) - Open DevTools and go to the Network tab. - Type in address bar: http://www.example.com/caching-1.html Chrome DevTools is showing "Size": 183 B The "Status Code" is: 200 OK GREEN The "Request Headers": "Provisional headers are shown" So it looks like there is no caching, otherwise the size would be "(from disk cache)" or "(from memory cache)". Anyway the size is now "183 B" and that's the size of the file itself. So going back to the definition: > Size. The combined size of the response headers plus the response body, as delivered by the server. If the server will respond with the body, then at least there must be some header response too (more Bytes). The size is 183 B and that's the size of the response body, so that's actually impossible. I repeated the second test, but now i changed the content file: caching-1.html. Chrome did not show any changes, so it means Chrome is taking the file from cache. Conclusion: Chrome DevTools is showing the wrong "Size" and actually also the wrong "Status Code". What is the expected behavior? Status Code:200 OK (from disk cache) Size: (from disk cache) instead of Status Code:200 OK Size: -variable- B What went wrong? Chrome DevTools is showing the wrong "Size" and actually also the wrong "Status Code". Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: 10.0 Flash Version: This "bug" can be very frustrated for webmasters. You think something is not coming from web cache, but actually it is. It took me a lot of time, so please do something about it, so other webmasters will not have the same problem.
,
Nov 16 2017
Unable to reproduce the issue on reported version 62.0.3202.94 and latest Canary 64.0.3269.3 using Windows 10 by following below steps mentioned in original comment Please verify screen-cast and let us know if we have missed any steps in the process of reproducing the issue from TE-End
,
Nov 16 2017
With example.com i did not mean literally example.com. That was an example of your own domain (same way like Google is using this in references). And anyway you did not follow the steps exactly with CONTROL N et cetera. So if you will follow the steps correctly, you will see the same behavior. More people tested this bug already, before i reported it here. So replace example.com with your own domain and then follow the steps correctly. Anyway it's pretty logical that you can not reproduce it when you are using a file from your computer, because then anyway there are no request and response headers. Are you part of Google?
,
Nov 16 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 17 2017
As per comment#3 this issue can't be tested with local html file. And also this issue looks similar to issue 763700 . cc'ing caseq@ from 763700 for further inputs on this. Thanks!
,
Nov 17 2017
Thanks for your useful comment! I searched in the history for this bug, but apparently i missed that one. I see now that 43 hours ago the status has been changed to "Fixed", while the bug was reported "September 10". Apparently it takes a while. But after the next Chrome update on my computer, this issue will not be there anymore? (because now the issue is still there)
,
Nov 17 2017
Thanks for the report, and thanks commenter #5 for finding the duplicate. The symptoms are the same. The fix from crbug.com/763700 is currently on Chrome Dev and Canary channels targeting Chrome M64. Today's stable Chrome is on M62, so you might have to wait for 2 new stable updates. Please follow the other bug for updates; it is possible they may merge the fix in sooner. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Nov 15 2017