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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 7 04:45:08 PDT 2017


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

            Bug ID: 170597
           Summary: Web Inspector: Compression inaccurately reported when
                    Content-Length header omitted
           Product: WebKit
           Version: Safari 10
          Hardware: Macintosh
                OS: macOS 10.12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Inspector
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: csswizardry at gmail.com
                CC: inspector-bugzilla-changes at group.apple.com

Created attachment 306487

  --> https://bugs.webkit.org/attachment.cgi?id=306487&action=review

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.

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.

**N.B.:** This is just a hunch, but I can’t draw any other lines between the cause and the problem. I may well be way off the mark here.

**Attachments:**

Attachment (2880×3600px, 647KB) shows two screenshots:

* Top shows annotated screenshot for **incorrectly** reported assets (2880×1800px, 511KB).
* Bottom shows annotated screenshot for **correctly** reported assets (2880×1800px, 511KB).

-- 
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/530d6450/attachment-0001.html>


More information about the webkit-unassigned mailing list