New issue
Advanced search Search tips

Issue 648546 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

transmitting file from server not working

Reported by nagur...@gmail.com, Sep 20 2016

Issue description

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

Example URL:

Steps to reproduce the problem:
1. when i click button from my website file not transmitted to local machine
2. existing version it works fine
3. response.close code was not working in this version.tried for so many ways.

What is the expected behavior?

What went wrong?
unable to work on our reports

Did this work before? N/A 

Chrome version: 53.0.2785.116  Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 23.0 r0
 
Labels: Needs-Feedback
Can you please provide a network internals log?  For instructions, see 

https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Comment 2 by nagur...@gmail.com, Sep 21 2016

I found through coding , That response.close and response.end not working in version 53. From past couple years it is working fine in older versions
net-internals-log (1).json
1.4 MB View Download

Comment 3 by mmenke@chromium.org, Sep 22 2016

Cc: mmenke@chromium.org
Components: -Internals>Network UI>Browser>Downloads
Status: WontFix (was: Unconfirmed)
The issue is that your server is sending an invalid response.  It's trying to send a chunked response, but doesn't send a terminal chunk.  As a result, Chrome doesn't know if the entire response has been received, or if the socket was erroneously closed.  Chrome used to incorrectly consider such transfers successes, but we've since fixed that bug.

You have a couple options to fix this:
1)  Send the terminal chunk(0\r\n\r\n, I believe).  Then you could even not close the socket, and reuse it for future requests, if you wanted.
2)  Don't send the response using chunked encoding.  This would technically make it an HTTP/1.0 response, I believe, though should work even if you continue to claim it's an HTTP/1.1 response.
3)  Send Content-Length and don't use chunked encoding.  If you don't know it in advance, obviously you can't do this (Unless oyu delay sending the headers until you know the content length).

Also worth noting that if connections can't be reused, you're best off sending a "Connection: Close" header, or advertising the response as HTTP/1.0.

Sign in to add a comment