[Webkit-unassigned] [Bug 170597] Web Inspector: Compression inaccurately reported when Content-Length header omitted

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 7 11:18:36 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=170597

--- Comment #3 from Brian Burg <bburg at apple.com> ---
(In reply to Harry Roberts from comment #0)
> Created attachment 306487 [details]
> Highlighted issues in screenshot
> 
> **Issue:** Network panel detects compression (e.g. gzip) but inaccurately
> reports transferred size and compression delta if `Content-Length` header is
> not provided.
> 
> **Steps to reproduce:**
> 
> A)
> 
> 1. Visit csswizardry.com
> 2. Open network panel with Size and Transferred columns visible
> 3. Hard reload page and inspect csswizardry.com document resource (i.e. the
> HTML page).
> 4. Notice that Size and Transferred values are similar (Transferred slightly
> larger to account for headers)
> 5. View csswizardry.com document resource (i.e. the HTML page) in Details
> sidebar.
> 6. Notice that Encoded/Decoded/Transferred size are also similar.
> 7. Compressed is marked Yes—Safari knew this resource was compressed.
> 8. Compression is set to 1×. Delta should actually be around 3.99× at time
> of writing.

I'm unable to verify this expected compression. When I save the file to disk it has a size of around 56KB and the reported transfer size is 55.09KB. This matches the compression of near 1x.

When I view this in Chrome, the transfer size is reported as 13.7KB, which matches your expected compression ratio.

So, either the displayed transfer size in Safari is wrong, or Safari didn't actually accept the gzip'd resource and actually transferred the uncompressed resource.

If you have server logs it should be possible to verify what's actually being sent. You could also try using Wireshark or something.

> 
> B)
> 
> 1. Follow the above steps for Twitter’s `widget.js` file.
> 2. Notice that Size and Transferred values are more like what we’d expect to
> see from a compressed (e.g. gzip) asset.
> 3. Compressed is also marked Yes—Safari knew this resource was compressed.
> 4. Notice that compression delta is 3.51×—much more like what we would
> expect to see.
> 
> C)
> 
> I know that my homepage *is* compressed, as does Safari, but it’s
> misreporting the Transferred size. By process of elimination, I noticed that
> the key difference between correctly reported and incorrectly reported
> values is that the correct assets have the Content-Length header present;
> incorrect assets have the Content-Length header missing. Ergo, I think the
> problem lies somewhere here.

This says to me that Safari might require Content-Length header to use compression.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170407/a1a0a964/attachment-0001.html>


More information about the webkit-unassigned mailing list