New issue
Advanced search Search tips

Issue 693934 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

response body hidden for fonts (h2)

Reported by benjamin...@pantheon.io, Feb 18 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Make a request for a font asset (e.g. /fonts/myfont.woff2)
2. Have the server serve a non-font response body (e.g. a http status reason phrase "Header overflow")
3. Observe devtools response tab displays "This request has no response data available"

What is the expected behavior?
The devtools response tab should show any printable response.

What went wrong?
devtools presumed the response would be non-printable based upon the asset type

Did this work before? N/A 

Chrome version: 56.0.2924.87  Channel: stable
OS Version: OS X 10.12.3
Flash Version: Shockwave Flash 24.0 r0

This is going to become increasingly more common as h2 (http2) adoption increases.

h2 does not support http status reason phrases (rfc7540 8.1.2.4), so we can expect to see these phrases returned as the response bodies.

 
Labels: Needs-Triage-M56
Cc: rbasuvula@chromium.org
Labels: TE-NeedsTriageHelp
This looks like out of scope for TE, hence adding the respective label for it to  triage further.
If I can help, please let me know.
Owner: allada@chromium.org
Status: Assigned (was: Unconfirmed)
Blaise, could you please take a look?

Comment 5 by allada@chromium.org, Apr 18 2017

Labels: -TE-NeedsTriageHelp -Needs-Triage-M56
This is a bigger scope than it seems. I believe we are going to be forced into re-thinking how we show resources to users, since H2 and Quik are breaking much of the old HTTP assumptions (like priority).

Even our ":" marker to show it's an H2 common header is not ideal since it's a bytecode (header compression). In the traditional sense we could just see the stream being terminated or something wrong with it and consider it failed, however with H2 it gets much more complicated. (and Quik is significantly worse, since each socket can hold multiple streams)

I am going to let this problem get a little bigger before I up the priority of it. I expect to see more pressure from netstack and loading teams and external adopters.

Thanks, I'll keep this bug around, but I probably won't start working around this area until we get more pressure.
Owner: caseq@chromium.org
Owner: jarhar@chromium.org

Sign in to add a comment