[Webkit-unassigned] [Bug 155112] Web Inspector: Doesn't show size of compressed content correctly
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Apr 12 18:54:33 PDT 2017
https://bugs.webkit.org/show_bug.cgi?id=155112
Joseph Pecoraro <joepeck at webkit.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |achristensen at apple.com,
| |bburg at apple.com,
| |beidson at apple.com,
| |joepeck at webkit.org,
| |koivisto at iki.fi
--- Comment #5 from Joseph Pecoraro <joepeck at webkit.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170413/53b29dba/attachment.html>
More information about the webkit-unassigned
mailing list