I just tried with chrome and osx and I cannot reproduce the problem (I tried with a 166MB file).
TIm, who made rocket, also claims he tried this extensively on windows and cannot reproduce the problem. I do not doubt you experience this issue. In order to try isolate better what may be causing it... is there anybody else having this problem with large files download? Massimo On Jun 20, 2:53 am, Stefan Scholl <[email protected]> wrote: > Sever OS: Linux (remote, behind Apache 2.2), Windows XP (local, > direct) > Client OS: Windows XP > Browser: Firefox 4, Internet Explorer 8 > Rocket version: 1.2.2 > > All combinations break the download for big files (33 MiB), > regardless of chunk_size or server. > > Only Internet Explorer 8 (all servers) had problems with small > files (160 KiB), before increasing chunk_size for the streamed > download. > > Made the changes to rocket.py (1.2.2), restarted web2py, and the > download was still broken. > > By the way: One of the new examples (Dog and owner registration, > with picture upload/download) doesn't use streamed download. It > reads the whole file and sends it. This method doesn't work for > big files, too. > > Massimo Di Pierro <[email protected]> wrote: > > > > > > > > > > > Can you make a list of combinations > > > browser name, version, server os, web server > > FF, 4, Windows 7, Rocket > > ... > > > for which you experienced the problem? > > > can you also try the following: > > 1) in the rocket.py code replace > > > 'HTTP/1.1 ' with 'HTTP/1.0 ' > > > and replace > > > environ['SERVER_PROTOCOL'] = request['protocol'] > > > with > > > environ['SERVER_PROTOCOL'] = "1.0" > > > Looks like acts as if the protocol of response is the same as the > > request but always declare the protocol of the response to be 1.1 even > > if the request is 1.0. This may result in keep-alive connections > > ignored by the browser. Perhaps this is part of the problem? > > > On Jun 17, 1:35 pm, Stefan Scholl <[email protected]> wrote: > >> To Massimo and the list/group: > > >> You asked on Reddit if the only constant is the browser. No it > >> isn't. But it was the browser which had the problem first, with > >> smaller files. > > >> For smaller files it was enough to raise the chunk_size. IE8 is > >> slow, maybe this is the reason? > > >> Firefox 4 failed when I tried to download a 33 MiB file remotely. > >> IE8 failed for anything above 64 KiB on localhost. > > >> It's almost as if Rocket is so fast because it sends without > >> regard for any receiver. Direct (localhost) or behind a proxy > >> (Apache 2.2 on the remote Linux server). > >> Don't know how this could happen. HTTP isn't ZModem. ;-) > > >> Stefan Scholl <[email protected]> wrote: > >> > I have a parameters_XXX.py file from the normal web2py (with > >> > rocket) and used the same IP and port with anyserver.py+Tornado > >> > (and the other one stopped, of course). > > >> > Tested with web2py 1.91.6. Were there any changes regarding this? > > >> > (I'm still very reluctant to upgrade this project.) > > >> > Massimo Di Pierro <[email protected]> wrote: > >> >> Try this: > > >> >> python > >> >>>>> from gluon.main import save_password > >> >>>>> save_password(raw_input('admin password: '),XXX) > > >> >> This will create a parameters_XXX.py file. It must be in the main > >> >> web2py folder. Caveats, the admin interface is disabled if you are not > >> >> form localhost and you are not using https. > >> >> Hope this helps. Hope to have you back on the mailing list. > > >> >> On Jun 17, 8:43 am, Stefan Scholl <[email protected]> wrote: > >> >>> Now I can't access the admin interface, because the password > >> >>> isn't set. (It isn't reading the stored password.) > > >> >>> Stefan Scholl <[email protected]> wrote: > >> >>> > OK, it was Rocket. > > >> >>> > Tested it with the old web2py and Tornado 1.2.1 via anyserver.py > >> >>> > and the download is OK. > > >> >>> > Stefan Scholl <[email protected]> wrote: > >> >>> >> The higher value for chunk_size didn't work with a 33 MiB file. Even > >> >>> >> in Firefox 4. > >> >>> >> So I tried 1.96.4 (Rocket 1.2.2) on Windows XP. > > >> >>> >> Made a new and simple app (dtest). The download there uses > >> >>> >> "response.download(request,db)" as well. > > >> >>> >> 1 simple table: db.define_table('stuff', Field('file', 'upload')) > > >> >>> >> Upload of the 33 MiB file via db admin, content listed on > >> >>> >>http://127.0.0.1:8001/dtest/default/data/select/stuff(default > >> >>> >> function "data" with "return dict(form=crud())". Download with > >> >>> >> Internet Explorer 8 (after removing the tag that switches to "Chrome > >> >>> >> Frame", to have a realistic test like "normal" users). > > >> >>> >> Download was broken. A few KiB were missing. This was on localhost. > >> >>> >> Remote tests have even worse results. > > >> >>> >> On 6 Mai, 17:51, Massimo Di Pierro <[email protected]> > >> >>> >> wrote: > >> >>> >>> Can you try 1.95.1 > > >> >>> >>> On May 6, 6:03 am, Stefan Scholl <[email protected]> wrote: > > >> >>> >>> > The classicdownloadfunction: > > >> >>> >>> > defdownload(): > >> >>> >>> > return response.download(request, db) > > >> >>> >>> > I'm developing on localhost (127.0.0.1, no SSL) and one strange > >> >>> >>> > thing > >> >>> >>> > happened: Downloads in IE8 (Windows XP) were all corrupt/broken > >> >>> >>> > if > >> >>> >>> > they weren't below 64KiB in size. Very easy to see with large > >> >>> >>> > images. > > >> >>> >>> > Using a higher value for the argument 'chunk_size' solves this > >> >>> >>> > problem, up to this new maximum. > > >> >>> >>> > web2py 1.91.6 > > >> -- > >> Web (en):http://www.no-spoon.de/-*-Web (de):http://www.frell.de/ > >> <!--[if IE 6]><script>for(x in document.open);</script><![endif]--> > > -- > Web (en):http://www.no-spoon.de/-*- Web (de):http://www.frell.de/ > <!--[if IE 6]><script>for(x in document.open);</script><![endif]-->
