UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Issue a POST upload multipart/form-data of some large file (1.2GB+)
2. Server side accepts the request headers, sees that the Content-Length exceeds some kind of configured limit on the server and returns response with error code (413 is a good choice) and closes the connection.
3. Browser does not see response, nor does the network panel in the debug tools.  Browser just reports a connection reset base error.

A simple embedded-jetty server showing this behavior of the browser can be found at (instructions on build / run found in README)

https://github.com/joakime/issue-1864  

Encourage you to upload a large file (I chose to use a fedora-core dvd iso at 1.4GB).  
Capture the traffic with wireshark (you'll see that the response was definitely sent)

What is the expected behavior?
The browser should recognize the response and behave as if it got the response.  

It is perfectly valid for a server to reject reading the request body.  It could be for policy reasons (413 too big of a file), it could be for authentication (403 you are not authorized), it could even be for an invalid endpoint (404 this doesn't exist).

The browser should recognize this response.
The debug tooling should recognize this response.
The network panel should show this response.

What went wrong?
The server didn't read the entire request (valid for HTTP/1.x) and responded with a response line (status code 413), response headers (with "Connection: close") and closed the connection.

The browser saw the closed connection, but didn't even bother to read the response that was present, instead just informing the user that the connection was reset.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: n/a
OS Version: 10.0
Flash Version: 

Curl (and other User-Agents) see and report the response correctly.

Note that reported behavior has only been tested against HTTP/1.1 (no other HTTP versions have been tested).

We believe this behavior in chrome has changed some time in the past 5 years.

We tested this back in the SPDY days, before the HTTP/2 spec finalization, and experienced the correct behavior, but sadly we cannot nail down the release that this behavior changed in.