DevTools: Protocol's encodedDataLength includes headers size |
|
Issue descriptionChrome Version : 60.0.3112.113 The protocol's "encodedDataLength", reported in Network.RequestFinished event, includes raw headers size, which it should not as far as the naming goes. There's already a code that seems to be subtracting headers which apparently doesn't work: https://cs.chromium.org/chromium/src/content/browser/loader/async_resource_handler.cc?sq=package:chromium&l=286 Reproduction case: - try serving an empty page and check it's "size" in devtools network panel Downstream issue in puppeteer: https://github.com/GoogleChrome/puppeteer/issues/667
,
Feb 9 2018
Apologies for posting on a closed issue, but I’m trying to work around the downstream issue in Puppeteer by subtracting the length of raw headers as suggested here and am running into a problem. It seems straightforward enough to subtract `Response.headersText.length` from `encodedDataLength` (assuming headers are ASCII, which seems safe enough 99% of the time, but is there a way not to make that assumption?). However, for HTTP/2 responses, `Response.headersText` is not present (it might be helpful to note that in the protocol viewer). I have a few questions in that case: 1. This seems reasonable since HTTP/2 headers are a special binary format and so have no canonical text representation. Is that correct, or is this a bug? (Happy to file one here if so.) 2. In this case (HTTP/2 responses), are the headers still included in `encodedDataLength`? 3. If yes to #2, how should I be calculating their size so I can subtract them from the overall `encodedDataLength` to get the response body bytes? Sorry if there’s somewhere obvious I should be looking for these answers in the Chromium source; I’m not familiar enough with it and don’t really know where to check. |
|
►
Sign in to add a comment |
|
Comment 1 by caseq@chromium.org
, Sep 22 2017Status: WontFix (was: Assigned)