New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 616546 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Wrong Network.dataReceived.encodedDataLength from the Remote Debugging Protocol

Reported by cyrus....@gmail.com, Jun 1 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36

Steps to reproduce the problem:
1. start Chrome with the `--remote-debugging-port=9222` option;
2. run `npm install chrome-remote-interface`;
3. in the same folder run `node reproduce.js`.

What is the expected behavior?
The sum of all the `encodedDataLength` (for each single object) should be equal to the corresponding `Content-Length` header.

Here is an example of expected output:

[1323.5] REQUEST WILL BE SENT
[1323.5] RESPONSE RECEIVED
[1323.5] Content-Length    = 606
[1323.5] dataLength        = 1270
[1323.5] encodedDataLength = 606
[1323.5] LOADING FINISHED

What went wrong?
The value is different (greater, it seems) from `Content-Length`.

Here is the actual output:

[1323.5] REQUEST WILL BE SENT
[1323.5] RESPONSE RECEIVED
[1323.5] Content-Length    = 606
[1323.5] dataLength        = 1270
[1323.5] encodedDataLength = 978
[1323.5] LOADING FINISHED

Did this work before? No 

Chrome version: 51.0.2704.63  Channel: stable
OS Version: Debian GNU/Linux 8
Flash Version: n.a.

For convenience, I've described how to reproduce this issue using a helper module [1]. The same can be obtained by manually reading from and writing to the WebSocket exposed by the Remote Debugging Protocol.

There is the possibility that I'm misunderstanding what `encodedDataLength` is. The documentation [2] states:

> Actual bytes received (might be less than dataLength for compressed encodings).

In this case the page is gzipped, so I'm expecting that the sum of all the `encodedDataLength` eventually gives the *on-the-wire* bytes that represents the body (i.e., excluding the headers). In other words:

    curl -s -H 'Accept-Encoding: gzip' http://example.com/ | wc -c

You can find more information at [3].

[1]: https://github.com/cyrus-and/chrome-remote-interface
[2]: https://chromedevtools.github.io/debugger-protocol-viewer/1-1/Network/#event-dataReceived
[3]: https://github.com/cyrus-and/chrome-har-capturer/issues/25
 
reproduce.js
1.2 KB View Download

Comment 1 by l...@chromium.org, Jun 9 2016

Cc: allada@chromium.org

Comment 2 by l...@chromium.org, Jun 9 2016

Status: Available (was: Unconfirmed)

Comment 3 by l...@chromium.org, Jun 9 2016

Cc: l...@chromium.org
Labels: Needs-Bisect
Owner: allada@chromium.org
Status: WontFix (was: Available)
This is not a bug. This is because one includes raw data including header information and one only includes content without header info.
That's right: 978 - 372 (the header size) = 606.
It might be convenient to clarify the description in the `protocol.json`.

Thanks for your time.
Cc: kayce@chromium.org
Yes, we are currently working to improve some of our documentation.

CC: kayce@ for FYI on #5

Sign in to add a comment