Forget it. (If this would be a real newsgroup I would cancel the article.) Forgot about the problems on localhost.
Stefan Scholl <[email protected]> wrote: > I had to do something perverted to save the project: I make a > local redirect to a PHP script, which uses readfile > <http://de.php.net/manual/en/function.readfile.php>. No problem > there. (Retrieving the original file name and content-type in > web2py.) > > It's only rocket. And it was reported by a co-worker and a > customer. > > One silly idea: What if Rocket has problems with some > proxies/firewalls? The customer has a broken proxy which caused > different problems for other projects. > > I don't know about any proxy at work, but it could be that they > reroute everything on port 80 through a proxy without me knowing. > (Ignore the non-technical implications of this assumption.) > > > Massimo Di Pierro <[email protected]> wrote: >> 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]--> >> > > -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ <!--[if IE 6]><script>for(x in document.open);</script><![endif]-->
