in the webdav tomcat sample application i have copied a very big file ( 6 Gigabytes ) i can see the file when i browse the directory with a browser and the size of the file is correctly displayed . when i try to download this file the resulting file is silently truncated to 2 Gigabytes i have tried several web clients to download ( firefox, wget, curl, cadaver ) on both linux and windows platform, with always the same truncated result. on the server side i have tested with both win2003 and linuxFC3 with both tomcat5.0.28 and tomcat5.5.10 and with both java1.4.2_08 and java1.5.0_04 ( to be honest, i have not tested all the possible combinations !) but every test produce the truncate problem. Regards
I think you should plan to investigate the issue yourself, as: - AFAIK large files work on the download direction (all people care about is that when dealing with large files) - few people care about WebDAV functionality beyond basic stuff
(In reply to comment #1) > I think you should plan to investigate the issue yourself, as: > - AFAIK large files work on the download direction (all people care about is > that when dealing with large files) Do you mean that people split their big files ? It may be a solution but it is not always possible ! > - few people care about WebDAV functionality beyond basic stuff I have made some more tests, and it happen also with a simple tomcat app without webdav functionality. Files between 2Gb and 4Gb do not produce the problem, only files > 4 Gb. Regards
I wrote (which I think was simple to understand): "I think you should plan to investigate the issue yourself". This means more than doing tests: start thinking about at least HTTP dumps as the minimum.
I uploaded and downloaded (the same file) a 2614816768 byte file without an issue. Using winxp and tomcat 5.1.{CVS HEAD}
idiot ... i meant 5.5.{cvs head}
He said only > 4GB was an issue. I think we should wait for at least HTTP dumps before we start testing this issue.
.
Although it is not possible to know for sure without appropriate information, there was a rather obvious defect in DefaultServlet, which causes a bad content-length for ranges > 2GB. As the only reasonable strategy for transferring such files is to use many single range requests, this was not tested well.