4.2.3 Is Here

LiteSpeed Web Server version 4.2.3 brings in some simple, but long-requested features.

First, an overview of what 4.2.3 has (then some more detailed treatment of some of the improvements):


  • A new option to hide the LiteSpeed signature in the default error pages.
  • The server can now use sendfile() to send back dynamic responses.
  • Updated documentation.
  • A new option to stop the server from aborting external application processes even when the client connection has been broken.
  • The PHP suEXEC daemon can now kill runaway child processes.
  • Connections have been reserved for the WebAdmin console to ensure accessibility regardless of the current number of connections.
  • The CGI daemon will now log processes killed by signals to stderr.
  • The PHP build utility (in the WebAdmin console) now supports PHP up to versions 5.3.25 and 5.4.15.

Bug Fixes:

  • Fixed a bug in how rewrite rules handled the FileETag directive.
  • Fixed a bug in FreeBSD realtime stats.

Hide the LiteSpeed error page signature: Does exactly what that says. The setting is in the WebAdmin console > Configuration > Server > General > Hide Error Page Signature. Choosing “Yes” will get rid of the words “Powered By LiteSpeed Web Server LiteSpeed Technologies is not responsible for administration and contents of this web site!” on your default error pages.

Sendfile() to send dynamic responses: sendfile() is much more efficient than using read() and write() to copy content. While sendfile() is often used to send static content, LSWS has now enabled sendfile() for dynamic content. This should mean much faster response times for large dynamic responses.

Documentation updates: We have been working hard to make our documentation more complete and up-to-date. Version 4.2.3 includes revised and clarified explanation tags for every setting in the WebAdmin console. We believe this will make LiteSpeed Web Server more accessible and easier to configure. We have also added/updated over 20 articles in our wiki. We will continue doing our best to make LSWS easier to use. Please let us know if there’s anything you want explained.

The new External Application Abort setting: (WebAdmin console > Configuration > Server > General) When a client breaks a connection with the the server, LiteSpeed Web Server can automatically abort external application processes generating responses for that client. Normally, you want LSWS to abort these runaway processes. There are some situations, though, where a user may wish to continue a process to the end whether or not the client is still connected (like a long-running process that you start yourself).

There are three options for this:

  • No Abort: Never abort external applications because of a broken connection.
  • Enable Abort for Requests from External IPs: Only processes started by requests from external IPs will be automatically aborted because of a broken connection. This is the default setting. It is a good setting if you have some internal long-running processes that you don’t plan to start from external IPs.
  • Enable Abort for All Requests: External application processes will be automatically aborted if the connection is broken, regardless of the source of the request.

Enjoy your newer, more responsive LiteSpeed. Remember, though, that for the first week or so we will still be fixing bugs that come up. If you want to stay away from the cutting edge, wait until we push it to the AutoUpdater. (You will get an email when it goes to autoupdate.)

More on the new version of PHP LSAPI tomorrow!

Tags: , , , , , , ,

6 Responses to “4.2.3 Is Here”

  1. bettinz says:

    I think the blog and the the new method with updated news and detailed wiki is a big but well done job 😉
    This is what I think is a detailed but complete changelog:

    As you can see, they release a lot of updates with new versions, like you (it’s normal with every new version), but they keep updated what change.

    So, this is how I work and I release my software:
    EDGE VERSION: 1.1, 1.3,1.5…
    Stable version: 1.2,1.4..

    In edge branch, i release sometimes hourly updates, but I keep this tracked in my changelog.
    So I have: 1.1.3, 1.1.7, etc
    When it’s stable, it will be, 1.2 with only rare bug fix for stable user.

    This is what I say about software release cycle some time ago (search in the forum with my nickname), and this is the change you need if you want an opensource community around LiteSpeed (the only release of OpenLitespeed is not enough, you need to change your software release cycle, in my opinion) 🙂

    • Michael says:

      Of course I remember your forum thread. It was that thread that spurred the blog post about version numbers.

      The biggest issue here, I think, is a question of priorities. I think that a developer section of the Enterprise site with a detailed changelog would be a good thing, but we don’t think it’s the most important thing right now. For Enterprise, we will continue to focus on fixing bugs, adding stable performance increases, trying to increase the compatibility of the software, and improving our documentation. (It’s worth noting that there are other examples of proprietary software that give abbreviated release notes — off the top of my head I can think of Plesk and IIS.)

      For OpenLiteSpeed, on the other hand, you are right, we will need to implement a way that people can see exactly what has been changed. Some open source projects do not include a detailed release log, but rather easy ways to diff the source codes. OpenLiteSpeed is still in its infancy and we are not sure exactly what method we will be using to make changes more clear. We are concentrating first on getting the code more stable and making the software easier to use. We will also be differentiating between OpenLiteSpeed 2.x (which will include more experimental advances), and OpenLiteSpeed 1.x (which will be the stable version, at first). For Enterprise, however, stability is always paramount.


  2. bettinz says:

    I think it’s important to create a new section for “developers” or for user with more skill.
    There are a lot of closed software with developer area: user can try new software, know every corrected bugs, and help to correct others with anonymous reports. What i say, is to split informations in two sections: a change log for the final user (who need a stable software and want to know what’s new) and one section for beta users, syaadmin with a lot of servers that can test your software in different enviroments and help with new functions.
    Now, in fact, only few users try 4.2.3, and others wait for a stable version. This can slow the bug hunting situation in my opinion.

    About the autoupdate: I mean, add the ability to update every day automatically, or when the package is updated; if i want to try 4.2.3, and it’s not full stable, maybe I want an automatic update for the 4.2.3 released tomorrow 🙂

    • Michael says:


      I think a developer’s section is an interesting idea, but I don’t think we’re going to be pursuing it at the moment. We do have a small but healthy community of of bleeding egde-ers who download new versions as soon as they come out and catch a good number of bugs. Of course we’d like to see that community expand, but, for the moment, we’re satisfied with this community’s (and our internal testing’s) ability to find important bugs and we feel there are other areas we need to pay attention to more. I, especially, will be looking to see if there are things we should be including in our release logs that aren’t there — and if anyone has an example of a bug fix that they feel should have been in the log but wasn’t, please email info(at)litespeedtech(dot)com — but it often seems that the next level of detail would involve very elaborate explanations of situation-specific errors. This, I believe, would cross the line of what is useful. But, again, it’s a fine line and if anyone has any examples that would help us find that line, I’d be very interested.

      I think it’s better that we focus on things like the autoupdate feature you mentioned (which we absolutely want to implement), updating and expanding our documentation, and improving our communication with the community (through places like this blog).


  3. bettinz says:

    Nothing about minor versions..i’ve read the blog’s post some weeks ago, and I understand the problem about bugs fix in few hours, but it’s important to know what happen from one build to another. If I download today, and this version contain an important bug that I can’t recognise or see, how can i know the cause? For example: download today, one site with a rewrite rule doesn’t work correctly; you fix the bug the day after, but I can’t know the cause is Litespeed, and I can’t manually update every day. So please enable the autoupdate for minor build.

    Remember: we can help you with bug fixing if we are quiet about updates. If I know what you fix, and what areas are critic, we can help you to make Litespeed better. And if i know what you fix today or tomorrow, we can say: yes, it’s fixed. You have a great community, and the better webserver. Thanks for the great work 😉

    • Michael says:


      So, you want a more detailed release log, right? We might be able to do that, but there’s a limit to the amount of data we can put in the release log. At a certain point it’s just going to become overloaded (both for us writing it and for you trying to figure out which bugs are important). We try to put bugs into the release log that we think have the possibility to affect a number of people (software compatibility issues, rewrite problems, etc…) and we’re trying to get more specific. Are there other kinds of bugs you would like to see in the release log?

      As for the autoupdate, it will be enabled as soon as we’re sure of the stability of the build. It’s been released now for users who want to try the newest build. In about a week, when we’re more sure it’s stable, we’ll push it to autoupdate.