Search results

you can PM Roman2K, see if he can help you on this. :-) The address should be something like "uds://tmp/lshttpd/<yourRubyAppName>.sock", About fcgi extapp configuration, you can take a look at: http://www.litespeedtech.com/docs/HowTo_QA.html#qa_extapp

OK, I see. That's due to how custom error pages was handled. The information about authentication realm was lost. We can't fix it right now, however, there is a work around though, set the customized error page to a URL under your protected context.

Is the gzip probem for dynamic content or static content? We will double check the problem related to admin interface.

No plan yet, it is demand driven. :-) And it probably will not be available for the standard edition if we build 64 bits binary. Some discussion here: http://www.litespeedtech.com/forum/viewtopic.php?p=1348#1348 Best Regards, George

Please download a copy of our LSAPI SAPI code for PHP from http://www.litespeedtech.com/lsapi/, then follow the instruction to patch your PHP code. Then use the configuration option in the output of phpinfo dump from our PHP binary. then make. There is a howto at...

Yes, if you search on the forum you will find. Instaed of patching ruby's fcgi code, you need to turn off fcgi persistent connection in the corresponding Ruby FCGI extapp configuration.

If the server is in product, it is not recommended to turn on the debug logging though. Anyway, the error.log should log something helpful when 403 happened without debug logging.

Thank you for your praise. Which error page has problem? 403 or 401?

The best way to debug this is to turn on debug logging by setting "Debug level" to "HIGH", then check lsws/logs/error.log Make sure that permission of the CGI script has been set properly, virutal host has not been restrained to its vhost root, script has been enabled.

Hi LLoyd, Thank you for trying our product. As we use PHP to build the directory index, in order for directory auto indexing, PHP have to be enabled in current LSWS release. We will put it on our to do list, and do not require php being enabled in future release. George Wang

Zoom, Thank you for trying our product. Have you configured the listener->vhost mapping under listener configuration? Have you configured index files properly? Also, check your lsws/logs/error.log, see if anything logged. And you can turn on the debug logging by setting "Debug Level"...

No. :-) We always try to publish new release to address the security issues ASAP.

Yes, you don't need to install openssl library just for LSWS

The result of ldd shows that lshttpd does not link to external OpenSSL library. I think we will not try FreeBSD 6.0 anytime soon, as 6.0 is too new to be used in production. :-)

As the openssl library is statically linked into our lsws binary. I think the problem may not be the openssl 0.9.8a library. You can doulbe check this by using "ldd lshttpd". I think the problem might be the FreeBSD 6.0, our prebuilt openssl binary does not work properly together with 6.0...

Sorry to hear that it is not successful. LiteSpeed can only proxy HTTP requests, other protocol is not supported. You need to find a ssh web client if you want ssh access through a web server.

LSWS 2.1.6 should be able to proxy svn requests to backend Apache. please give it a try. :-) George

This issue should be fixed in the 2.1.6 release.

Thank you for using our product and your praise. Instead of define a script handler for htm, you can let lsws forward all requests for that virtual host to the backend server with Proxy context with URI '/'. Problem with your current configuration probably is, that when you access...

Btw. why is it so hard to get the PATH_INFO working correctly? Isn't there a chance to get it fixed in the main php-distro? Due to lost information in Apache's fcgi interface, FCGI PHP have to extrace information from the original request URL, there is no information lose in LSWS' fcgi...