Closed
Bug 604037
Opened 14 years ago
Closed 8 years ago
Bad Networking Causes a 20MB-sized file downloading error at only <20MB got but taken as "downloaded"
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ctengctsh, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.10) 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-1.5.8.0-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
Comment 1•14 years ago
|
||
"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.
Comment 2•14 years ago
|
||
(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.
Comment 3•8 years ago
|
||
history shows comment 1 is right
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Comment 4•8 years ago
|
||
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.
Description
•