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

Issue 757380 link

Starred by 2 users

Issue metadata

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



Sign in to add a comment

DevTools Network Response. The response body is not displayed if its size is more than ~10 000 000 characters

Reported by rammxx...@gmail.com, Aug 21 2017

Issue description

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

Steps to reproduce the problem:
1. Generate text file (for example test.html) on 10000 lines. In every line of 1000 characters. All characters are the English letters
2. Open the file in a chrome
3. The browser shows file contents completely
4. Open devTools->Network
5. Reload the page
6. If to open on a network from the server, it is visible in column size that the size of data retrieved is not empty. (in my case 42.9KB)
7. But if to click on the file to view Response or Preview, there is "Failed to load response data"
8. If to reduce file size for example to 9000 lines, then everything is ok
9. It is possible to find up the exact size when adding one character is cause of show "Failed to load response data" instead of file contents

What is the expected behavior?
It is expected that instead of the message of "Failed to load response data", file contents, or at least a part of the file will be shown if the text is too big.
It brings inconveniences especially in case of ajax of requests

What went wrong?
it is not possible to view a response body

Did this work before? N/A 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

1. It repeats not only in MAC OS X but also on WINDOWS with an accuracy of character
2. It repeats with local files
3. The exact quantity of characters depends on body content. Sometimes it is ~5000000 characters, sometimes ~10000000
 
test.html
9.5 MB View Download
Labels: Needs-Triage-M60 Needs-Bisect

Comment 2 by hdodda@chromium.org, Aug 22 2017

Cc: hdodda@chromium.org
Labels: -Needs-Bisect M-62 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Tested the issue on windows 10 , ubuntu 14.04 and Mac OS 10.12.6 using chrome M60 #60.0.3112.101 and M62 #62.0.3192.0 and issue is reproduced.

This is a Non-regression issue seen from M45.

Hence, marking it as untraiged for further inputs on this.

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

Comment 4 by allada@chromium.org, Sep 21 2017

Status: WontFix (was: Assigned)
It is more of a limitation to the way the backend is implemented. We store the data before it gets garbage collected unless there is no room (which this is likely the case). Since it's stored in a weak map, we do not know why we cannot retrieve the data other than the fact that it's not there.

Since this is such an extreme use case I am going to mark as WontFix. You can still get the data via a proxy and I believe chrome://net-internals.

Thanks for the report though!

Sign in to add a comment