User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:184.108.40.206) Gecko/20100914 Firefox/3.6.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:220.127.116.11) Gecko/20100914 Firefox/3.6.10 Due to the networking problem(low ratio, or GFW, i think), A 20MB sized http file （http://tortoisegit.googlecode.com/files/TortoiseGit-18.104.22.168-32bit.msi）only got 10MB downloaded But App 'thinks' it was successfully downloaded This is not acceptable. Reproducible: Sometimes Steps to Reproduce: 1.Make a customed HTTP server, which first give agent a file size hint X MB 2.Then send data to agent client, but close connection at Y MB( Y<X) Or due to middle firewall problem ...? 3.Networking core should report "File is download", But in fact it's NOT
"File size hint" as in Content-Length? In practice, it's common for those to be wrong; if the server doing a clean connection close then we have no way to tell that something is broken.
(In reply to comment #1) > "File size hint" as in Content-Length? > > In practice, it's common for those to be wrong; if the server doing a clean > connection close then we have no way to tell that something is broken. While I understand the sentiment, I feel like that is too strong of a statement. The server in this bug did everything right - it correctly framed a 20MB response. We didn't get 20MB and therefore have a reasonable basis for declaring something fishy. Its actually a pretty strong signal. TCP semantics aren't all that helpful as TCP doesn't have to be end-to-end with the HTTP response. If we're in a path with something like a dom parser or an image renderer then it makes sense to just ignore the fishiness as those things are reasonably self delimiting. But the download manager could at least annotate the response. (e.g. instead of cancelled or OK it could say warning..) where do you see common incorrect CL's? Especially ones that are too long? on dynamically generated content I sometimes see a CL that is too short by a byte or two, generally not accounting for a trailing new line but that's about it.
history shows comment 1 is right
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
actually, content-length is mostly right, but lots of times http framing is incorrect. c-l is a better indicator and the download manager uses it when it is available.
You need to log in before you can comment on or make changes to this bug.