1.5.0 works on win32 natively - again 15
Half a year ago I was traveling a bit and tried to get lighty to compile natively on win32
Some time has passed and I concentrated on the other stuff in the 1.5.0 tree, leaving the nasty win32 code in place for someone to pick up. Ben Harper aka rogojin has picked it up and released a win32 installer for the latest pre-release
A simple tests shows that staticfiles are working nicely and that http-proxying with mod-proxy-core works too. Nice work, Ben.
Trackbacks
Use the following link to trackback from your own site:
http://blog.lighttpd.net/articles/trackback/2574
Comments
-
It can compile on MingW?
-
It can compile on MingW?
-
I have only tried VC 2005. Will send the source soon.
-
I HAVE ANXIOUSLY waited to have this native version. Cause I have a PROduction site with about 300 K transactions per day and I plan to run Lighty with it. On DEVelopment site, Lighty is fine already. However, I have seen that X-SENDFILE will not work. And that is ESSENTIAL for me. Using Kevin's Win32 version (1.4.11), it works fine. Under which circumstances X-SENDFILE does not work ? Any plans on fixing it ? Thanks !
-
x-sendfile does not work when used from one of the mod_proxy_core backends (which is the only way you can really use x-sendfile in 1.5.0). I will make sure it works in the new year (if nobody else does it before me), but I'm away until January. What kind of site is it (PHP, FastCGI, etc)?
-
I have my own EXTERNAL FastCGI server that I build completelly in XBase++ (Clipper successor). X-SENDFILE is very used cause this FastCGI server will "tell" the http server a file path to be delivered to the browser. This file path is from a repository of JPG files stored on a SCSI drive, on several different folders. So, the answer from the FastCGI server is simply the file path. Thanks !
-
I have my own EXTERNAL FastCGI server that I build completelly in XBase++ (Clipper successor). X-SENDFILE is very used cause this FastCGI server will "tell" the http server a file path to be delivered to the browser. This file path is from a repository of JPG files stored on a SCSI drive, on several different folders. So, the answer from the FastCGI server is simply the file path. Thanks !
-
I see.. When I return, I will try my best to make sure that the native win32 is stable under heavy load. Right now it's quite easy to crash it. If I get time I'll also look at making it scale better, and perhaps implement the win32 parallel of some of the optimizations that have been done for the other operating systems.
-
I get the following message: The application could not be started. SSLEAY32.dll could not be found. Reinstalling the application might solve this problem. System: Windows XP "Professional" :-), the usual assortment of service packs and fixes and a cygwin so I won't miss UNIX too much... Regards, Andre
-
Ben it seems you missed ssleay32.dll in your installer. is this on purpose or a packaging bug?
-
The omission of ssleay32.dll was a packaging bug. I'll make sure to test the installs on a clean VM in future.
-
I have tried to install this version but I noticed that mod_fastcgi is not embeded. Is it supposed to be like that ? I need to text an external FastCGI server....
-
Adriano: mod_fastcgi has been subsumed by mod_proxy_core in 1.5.0. Ben: Thanks for sending me the missiing file. Regards, Andre
-
Ben, could you update your package with the SSLEAY32.dll in your blog please? I'm stuck on windows but I'd like to test the 1.5 version. Thanks
-
Andre Bogus: How do I configure mod_proxy_core to use an external fastcgi server ? IOW, where's 1.5 documentation ?