-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Cannasse a écrit : > KaalH! a écrit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Nicolas Cannasse a écrit : >>>>> Another possibility would be to have an abstract protocol API that is >>>>> implemented differently in mod_tora.c (or lighty_tora.c). >>>>> >>>>> Nicolas >>>>> >>>>> >>>> >>>> This is a tora proxy backend implementation for >>>> lighttpd 1.5.0 >= r1992 :) >>>> >>>> lighttpd proxy layer allow load balancing & failover for free, that's >>>> why I've use it instead of a standalone module. >> >> I've optimized the lighttpd patch, I've remove some duplicate buffers >> and now directly use temp files, updated version attached. >> >> It's still parse all multipart data from temp files to find boundaries >> positions before starting to send anything to tora, which can be quite >> long, so timeouts can occurs with (very) large uploads. >> >> You set the tora socket timeout to 3 seconds, it is possible to increase >> it by default without side effects ? or having a command line option for >> it ? > > I'm not a big fan of inscreasing the timeout, since it shouldn't depend > on that for handling large files. Is it not possible instead to stream > the data while parsing it like mod_tora for apache does ?
With other proxy backends (fastcgi,ajp13,http,scgi), raw data is sent as is or splitted in fixed length data packets, final decoding is made by the proxied server. Adding smthg like CMultiBoundary & CMultiData to the tora protocol and decode data in the server would be better for lighttpd. I've may found a bug with getMultipart() during my tests, data seems to be kept in memory, consecutive requests increase tora memory consumption. > >>> Thanks, I'll have a look at integrating that in mod_tora. I'll maybe >>> refactor a big chunk of protocol.* in order to separate the apache parts >>> from the other ones. >> >> Great, tell me when done then I'll update the lighttpd patch. >> >> Do you think we should create a page on the haxe wiki for this patch >> now, or is it better to wait for protocol.* refactoring ? > > I'll try to refactor soon, so better wait a little more. ok Kaalh > > Best, > Nicolas > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6henWRw620CDc80RAuUJAJ9Zl04UryjgDBveZPr41+5sfw3/ZACfdqit sC5wbraKRDfgOYVNmd4j11k= =dy62 -----END PGP SIGNATURE----- -- Neko : One VM to run them all (http://nekovm.org)
