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
,
Jun 9 2016
,
Jun 9 2016
,
Jun 9 2016
This is not a bug. This is because one includes raw data including header information and one only includes content without header info.
,
Jun 9 2016
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.
,
Jun 9 2016
Yes, we are currently working to improve some of our documentation. CC: kayce@ for FYI on #5 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by l...@chromium.org
, Jun 9 2016