Summary: | Web Inspector: Doesn't show size of compressed content correctly | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Martin Häcker <spamfaenger> | ||||||||||||||||||||||||
Component: | Web Inspector | Assignee: | Joseph Pecoraro <joepeck> | ||||||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||||||
Severity: | Normal | CC: | achristensen, bburg, beidson, buildbot, csswizardry, graouts, hartman.wiki, inspector-bugzilla-changes, joepeck, keith_miller, koivisto, mark.lam, mattbaker, msaboff, rniwa, saam, timothy, webkit-bug-importer | ||||||||||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||||||||
Hardware: | All | ||||||||||||||||||||||||||
OS: | All | ||||||||||||||||||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=158463 | ||||||||||||||||||||||||||
Bug Depends on: | |||||||||||||||||||||||||||
Bug Blocks: | 28812, 32026 | ||||||||||||||||||||||||||
Attachments: |
|
Description
Martin Häcker
2016-03-07 07:51:45 PST
Created attachment 273180 [details]
Screenshot showing the problem
*** Bug 170597 has been marked as a duplicate of this bug. *** In Safari using NSURLSession (CFNetwork) we don't currently have a way to get the number of encoded bytes received by the network connection for the Resource Body. The existing API (-[NSURLSession countOfBytesReceived]) gives the number of decoded bytes, and that is what we are seeing right now in Web Inspector. Eventually we will want access to the encoded size during the download so that we can accurately report the encoded/decoded size of the resource while the load is ongoing. That is tracked by Bug 158463. <https://webkit.org/b/158463> Network: Correctly report encoded data length (transfer size) from CFNetwork to NetworkResourceLoader Web Inspector is smart enough to fall-back to using the "Content-Length" header to display an encoded transfer size for resources, but that is not always available. For example see bug 170597 for a detailed account and examples: <https://webkit.org/b/170597> Web Inspector: Compression inaccurately reported when Content-Length header omitted -- We can use new CFNetwork SPI to get more complete metrics about network transfer sizes: - request headers size - request body size - response headers size - response body size (encoded) - response body size (decoded) This gives us information we didn't have before (header sizes, request sizes). I'm going to use this bug to track using those metrics. That will allow Web Inspector to show accurate sizes once a resource has fully loaded. *** Bug 163295 has been marked as a duplicate of this bug. *** Created attachment 306967 [details]
[PATCH] Work in Progress
The tests will fail on all EWS ports right now. I'm going to test on a 2nd machine tomorrow to see how I should handle older systems.
Created attachment 307050 [details]
[PATCH] For Bots
Comment on attachment 307050 [details] [PATCH] For Bots Attachment 307050 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/3531425 New failing tests: http/tests/inspector/network/resource-sizes-network.html Created attachment 307066 [details]
Archive of layout-test-results from ews103 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 307050 [details] [PATCH] For Bots Attachment 307050 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3531397 New failing tests: http/tests/inspector/network/resource-sizes-network.html Created attachment 307067 [details]
Archive of layout-test-results from ews117 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 307050 [details] [PATCH] For Bots Attachment 307050 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/3531432 New failing tests: http/tests/inspector/network/resource-sizes-network.html Created attachment 307068 [details]
Archive of layout-test-results from ews107 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 307071 [details]
[PATCH] Proposed Fix
Alright! This should now be reviewable.
I think we should get a review from an Inspector person (Brian / Matt / Tim)? and a Networking person (Alex / Brady / Antti)?
Comment on attachment 307071 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307071&action=review > Source/WebInspectorUI/UserInterface/Models/Resource.js:489 > + // for estimatedTransferSize. So prefer the "Content-Length" property Comment style: only need one space after period. > Source/WebInspectorUI/UserInterface/Models/Resource.js:532 > + return !!(contentEncoding && /\b(?:gzip|deflate)\b/.test(contentEncoding)); Good catch, looks like we previously returned undefined or true. > Source/WebInspectorUI/UserInterface/Models/Resource.js:616 > + this._estimatedResponseHeadersSize = String(this._statusCode).length + this._statusText.length + 12; // Extra length is for "HTTP/1.1 ", " ", and "\r\n". What about: const headerBaseSize = 12; // Length of "HTTP/1.1 ", " ", and "\r\n"; this._estimatedResponseHeadersSize = String(this._statusCode).length + this._statusText.length + headerBaseSize; > Source/WebInspectorUI/UserInterface/Models/Resource.js:618 > + this._estimatedResponseHeadersSize += name.length + this._responseHeaders[name].length + 4; // Extra length is for ": ", and "\r\n". Ditto. > Source/WebInspectorUI/UserInterface/Models/Resource.js:720 > + var previousSize = this._estimatedSize; let Comment on attachment 307071 [details] [PATCH] Proposed Fix Attachment 307071 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/3531812 New failing tests: http/tests/inspector/network/resource-sizes-network.html Created attachment 307077 [details]
Archive of layout-test-results from ews105 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 307078 [details]
[PATCH] Proposed Fix
Created attachment 307080 [details]
[PATCH] Proposed Fix
Addressed Matt's comments.
Comment on attachment 307080 [details]
[PATCH] Proposed Fix
Inspector parts look good.
Comment on attachment 307080 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307080&action=review > Source/WebInspectorUI/UserInterface/Models/Resource.js:490 > + // macOS provides the decoded transfer size instead of the encoded size > + // for estimatedTransferSize. So prefer the "Content-Length" property > + // on mac if it is available. I can add the bug number tracking this: <https://webkit.org/b/158463> Network: Correctly report encoded data length (transfer size) from CFNetwork to NetworkResourceLoader Comment on attachment 307080 [details] [PATCH] Proposed Fix Attachment 307080 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3536339 New failing tests: webrtc/multi-video.html Created attachment 307174 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Comment on attachment 307080 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307080&action=review > LayoutTests/platform/mac/http/tests/inspector/network/resource-sizes-network-expected.txt:14 > +FAIL: networkEncodedSize should be exactly 2955 bytes. > + Expected: 2955 > + Actual: NaN What's this about? > Source/WebCore/platform/spi/cf/CFNetworkSPI.h:128 > +@property (assign, readonly) NSInteger _requestHeaderBytesSent; Is this SPI available on all platforms? Comment on attachment 307080 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307080&action=review I think we shouldn't check in tests with a FAIL expectation without some kind of explanation of what that means. Also, I'm not sure the SPI exists everywhere. Other than that, I think the network code looks good. > Source/WebCore/platform/network/NetworkLoadMetrics.h:104 > + requestHeaderBytesSent = std::nullopt; Note: in another patch, we should replace the Seconds values that are -1 right now if there is no value with std::optional<Seconds> > Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp:625 > + networkLoadMetrics.responseHeaderBytesReceived = 0; Does the inspector have an indication that this resource was retrieved from the cache? Does anyone care how many bytes were pulled from the cache? It's obviously different from bytes received over the network, but maybe there should be a difference between a 0 byte resource and a resource from the cache. Comment on attachment 307080 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307080&action=review >> LayoutTests/platform/mac/http/tests/inspector/network/resource-sizes-network-expected.txt:14 >> + Actual: NaN > > What's this about? This is a platform expectation for Mac because as mentioned in the ChangeLog: Older versions of macOS will not have the new metrics... Older cocoa platforms will be using the "estimated*" methods, which are tested here. If you want I could hide NaN output, but I'd still want to include platform expectations for older macOSes so that their code pathes are still tested. >> Source/WebCore/platform/spi/cf/CFNetworkSPI.h:128 >> +@property (assign, readonly) NSInteger _requestHeaderBytesSent; > > Is this SPI available on all platforms? No, just out of range of the Review Tools is this condition wrapping this class extension: #if (PLATFORM(MAC) && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || (PLATFORM(IOS) && __IPHONE_OS_VERSION_MIN_REQUIRED >= 110000) Comment on attachment 307080 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=307080&action=review >> Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp:625 >> + networkLoadMetrics.responseHeaderBytesReceived = 0; > > Does the inspector have an indication that this resource was retrieved from the cache? Does anyone care how many bytes were pulled from the cache? It's obviously different from bytes received over the network, but maybe there should be a difference between a 0 byte resource and a resource from the cache. Yes, the inspector will know that this resource was loaded through the DiskCache. (Likewise it identifies resources loaded through the MemoryCache). Right now I'm more interested in showing the exact number of bytes that went over the network in Web Inspector. I'm not sure knowing how a disk cached resource was stored (possibly compressed or not) will be as interesting to web developers as that is an implementation detail of WebKit. Ping reviewers. I answered Alex's questions and I don't think they required any changes to the existing patch. |