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

Issue 842153 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

ERR_RESPONSE_HEADERS_TOO_BIG size is too small.

Reported by discc...@gmail.com, May 11 2018

Issue description

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

Steps to reproduce the problem:
1. Load a request with headers larger than 250KB.
2. 
3. 

What is the expected behavior?
Don't limit header sizes.

What went wrong?
Chrome displays ERR_RESPONSE_HEADERS_TOO_BIG and fails to load the page.

Did this work before? No 

Chrome version: 66.0.3359.139  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

Why limit header sizes at all?
Sending data to the browser through the browser can be extremely useful, as this occurs out of band from the content of the response body. Any data type can be returned in the response body: html, xml, json, binary, etc. The header provides a way to communicate additional metadata about the response which can then be utilized by the browser. One great example is to enable server side tracing which can then be displayed in developer tools (see: Chrome Logger).
 

Comment 1 by alph@chromium.org, May 12 2018

Components: -Platform>DevTools Internals>Network
Labels: Needs-Triage-M66
Labels: Triaged-ET Needs-Feedback
@Reporter: Please provide sample file/test URL to test this issue from TE end. Any further information on reproducing the issue would help in better triaging of this.

Thanks!
As per this comment:
https://bugs.chromium.org/p/chromium/issues/detail?id=455330#c5
having a limit on header size facilitates designing and testing of a browser by setting known bounds on an otherwise unknown quantity which allows developers to better plan for how to handle and treat the header data.

Instead of including the server side trace in headers, could you instead include an identifier (perhaps a URL of a visualization of the trace) that could be used to fetch the particular server side trace if desired later?  This would avoid wasting bandwidth in cases where the trace wasn't desired.

Comment 5 by discc...@gmail.com, May 16 2018

"Our limit is 64k, I believe...And surely that should be enough for anybody." ;)

If setting an arbitrary limit, at least set one high enough to allow some innovative uses of the headers.

"Test results from MacBook running Mac OS X 10.6.4:

Biggest response successfully loaded, all data in one header:

Opera 10: 150MB
Safari 5: 20MB
IE 6 via Wine: 10MB
Chrome 5: 250KB
Firefox 3.6: 10KB"
-https://stackoverflow.com/questions/3326210/can-http-headers-be-too-big-for-browsers




Project Member

Comment 6 by sheriffbot@chromium.org, May 16 2018

Cc: sindhu.chelamcherla@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by mmenke@chromium.org, May 16 2018

Status: WontFix (was: Unconfirmed)
Providing unlimited system resources in the browser process to a remote site can cause crashes, particularly on memory limited devices.  Given that this hasn't been a problem in the past decade, don't think we need to change this.

Sign in to add a comment