Search results

Thanks for the quick response! Any idea on how soon we might expect a 4.2.2 release?

I'm trying to deploy a new REST API that we developed and it uses the "PATCH" HTTP verb/method to modify server-side resources. Here's what Litespeed logs on an example PATCH request: 2013-01-24 13:31:17.864 [INFO] [199.47.220.172:37018-0] Status 400: Bad request method: PATCH /stores/66...

OK, managed to fix this by manually editing the Litespeed listener configuration. I used the ciphers recommended for fixing the BEAST vulnerability in Apache: <listener> <!-- ... -->...

I'm trying to get our server to prefer the RC4 cipher over others so that we defend against the BEAST vulnerability. Using Qualys' SSL tool, here's what I get when I scan our server: http://cl.ly/image/2C261x0x3927 RC4 should be at the top of that list. We have changed the SSL listener...

Good idea, thanks. However, in this particular case it won't help — the script needs to stay "on the line" to make sure the browser completely received the download before doing some accounting and recording the completed download. Think of where you sell a customer an eBook, you only want...

I agree, but I can't find where in the PHP engine this happens. I find that it specially disables "zlib.output_compression" for image/* response MIME types, but can't find anything that implicitly enables "zlib.output_compression" based on that header's presence.

So, I fixed the problem, but the cause is still a mystery. It turns out that the PHP zlib.output_compression setting WAS turned on for this script, which is surprising because I explicitly disabled in the site's .htaccess, and it's not in the "Apache-style settings" in the Litespeed control...

OK, after some more testing, it looks like a this bug with PHP's memory-mapped IO. When I do a loop in the script to stream the file contents out 8K at a time, it works, although it eats up crazy CPU. I'm going to work more to see if I can find why this is triggered by the gzip/deflate...

OK, just tried bumping PHP's memory limit to 500M, same result. Also note that Litespeed's external app memory limits for lsphp5 are: - Soft limit: 600M - Hard limit: 1000M I assume that the since the PHP interpreter's limit is set lower that will govern the actual memory limits.

/usr/local/lsws/fcgi-bin/lsphp5 -i | grep memory_limit memory_limit => 200M => 200M That reminds me, I bumped the memory_limit from 128M to 200M when I started having trouble. I may try bumping it up really high to see if that solves the problem. I looked at the source to PHP's...

Hello! First off, let me thank you for a great server; we replaced Apache with Litespeed about 6 months ago and it's been rock solid. I'm running into a problem right now with PHP scripts who output more than around 120MB of data. When I use curl to request the file, it works fine: > GET...