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

Issue 677862 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

har export response headersSize and bodySize are always -1 for http2 or spdy resources

Reported by les.mur...@eperformancegroup.com, Jan 3 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. Open Devtools Network Tab
2. Navigate to an HTTP2 site (e.g. www.google.com or www.yahoo.com)
3. Save HAR file
4. Open HAR file.  Observe that the headersSize and bodySize  are -1 for response objects.  The headersSize is always -1 for requests objects.
5. Repeat for a non SPDY non H2 site.  In those cases the HAR fields are populated correctly

What is the expected behavior?
headersSize  and bodySize  should reflect the sizes of the respective items.  The headersSize should reflect the H1 (plaintext) length of the headers.

What went wrong?
HAR export values are always -1 for SPDY and HTTP2 resources.

Tools that analyze HAR files (for example https://ericduran.github.io/chromeHAR/ ) will show misleading results because the "wire" length of the resource is not captured.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

It looks like on a GET or POST the bodySize is set correctly for a h2 request object.

Ideally there would be an additional json object, for example "_http2_info" with items such as the streamId, streamPriority, pushFlag, pushRejectFlag, totalHeadersSize.  The totalHeadersSize in this object would be the compressed HPACK size of the headers.
 
shimmercat.har
1.6 MB Download
Shimmercat HAR viewer.png
98.7 KB View Download

Comment 1 by ajha@chromium.org, Jan 4 2017

Labels: Needs-Triage-M55
Labels: -Needs-Triage-M55 M-57 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Win 10,Mac 10.12.2 and Ubuntu 14.04 using 55.0.2883.87/95 and canary 57.0.2970.0.
This is a non-regression issue since 46.0.2490.86, as was unable to load har file into https://ericduran.github.io/chromeHAR/ prior to it. 

Untriaged to get addressed further.

Comment 3 by alph@chromium.org, Jan 10 2017

Owner: allada@chromium.org
Status: Assigned (was: Untriaged)

Comment 4 by kotah@chromium.org, Feb 17 2017

Cc: kotah@chromium.org
Labels: Hotlist-Enterprise OS-Chrome
Any update on this? HAR export feature is widely used within enterprise & education support team to assist users with debugging G Suite (Gmail, Drive, etc.) frontend issues, and most of G Suite services support HTTP/2.

Comment 5 by kotah@chromium.org, Feb 20 2017

Labels: -Hotlist-Enterprise -OS-Chrome
Pls ignore #c4, I was mixing this up with  crbug.com/668032  :)

Comment 6 by allada@chromium.org, Jul 20 2017

Status: Fixed (was: Assigned)
There was recently a refactor of much of this code. If you are experiencing bugs like this, please open a new bug.

Thanks!

Sign in to add a comment