New issue
Advanced search Search tips

Issue 775773 link

Starred by 1 user
Status: Duplicate
Merged: issue 763700
Owner: ----
Closed: Oct 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Incorrect value for encodedDataLength

Reported by mem...@lenglet.name, Oct 18 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0

Steps to reproduce the problem:
Watch the Chrome WebDevTools protocol and the net-internal logs:

1. Start Chrome with remote protocol opened: `open -a "Google Chrome Canary" --args --remote-debugging-port=9222 http://example.com` 
2. Open in an other browser: `open -a "Google Chrome" --args http://localhost:9222/`
3. Select the corresponding page
4. Inspect the webdev tool page and open the network tab
5. Disable the cache
6. Select the Network request entry start with `ws://localhost:9222/devtools/page/` and open the "Frames" tab panel
7. In parallel open in Canary a new tab `chrome://net-internals/#events`

What is the expected behavior?
The value of the field `frame.params.encodedDataLength` in the `Network.loadingFinished` frame should be 934 bytes: 328 (`frame.params.response.headersText.length` from `Network.responseReceived` frame) + 606 bytes (the response body size)

What went wrong?
The value of the field `frame.params.encodedDataLength` in the `Network.loadingFinished` frame is equal to 1598 bytes

It's the value of headers + unzipped body content (dataLength)

Did this work before? N/A 

Chrome version: 64.0.3242.0 (Build officiel) canary (64 bits)  Channel: canary
OS Version: OS X 10.12
Flash Version: Shockwave Flash 27.0 r0

- frames_crumbs.log contains few frames of Chrome WebDevTools protocol
- net-internal_request.log contains the log entry where the interesting parts are:

------------
...
t=1858 [st=79]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                      --> HTTP/1.1 200 OK
                          ...
...
t=1859 [st=80]      URL_REQUEST_FILTERS_SET
                    --> filters = "GZIP"
...
t=1860 [st=81]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 606
t=1860 [st=81]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 1270
...
------------

- WebDevTools_network.png is a screenshot of WebDevTools network tab where the result are displayed incorrectly, because the WebDevTools protocol provide the wrong information
frames_crumbs.log
709 bytes View Download
net-internal_request.log
3.5 KB View Download
WebDevTools_network.png
58.2 KB View Download

Comment 1 by mem...@lenglet.name, Oct 18 2017 

A more obvious example: http://i0n46ycwiz.kameleoon.eu/

In network panel both values (body size and transferred size) are 595KiB (~609KB), where the Content-Length is 93245 bytes

Transferred size:

echo -e "GET / HTTP/1.1\r\nHost: i0n46ycwiz.kameleoon.eu\r\nAccept-Encoding: gzip, deflate\r\n" | nc 192.229.233.4 80 | wc -c
> 93608

Body size:

echo -e "GET / HTTP/1.1\r\nHost: i0n46ycwiz.kameleoon.eu\r\nAccept-Encoding: gzip, deflate\r\n" | nc 192.229.233.4 80 | sed ':a;N;$!ba;s/^.*\r\n\r\n//g' | gzip -d | wc -c
> 609052

Comment 2 by ajha@chromium.org, Oct 18 2017

Labels: Needs-Triage-M64

Comment 3 by mem...@lenglet.name, Oct 18 2017 

To be exact we should also add the "empty line" https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_message:

The value of the field `frame.params.encodedDataLength` in the `Network.loadingFinished` frame should be 934 bytes: 328 (`frame.params.response.headersText.length` from `Network.responseReceived` frame) + 2 ("\r\n") + 606 bytes (the response body size)

Comment 4 by dgozman@chromium.org, Oct 23 2017

Mergedinto: 763700
Status: Duplicate (was: Unconfirmed)
I think this is another manifestation of  issue 763700 .
►

Sign in to add a comment