Hubbry Logo
LighttpdLighttpdMain
Open search
Lighttpd
Community hub
Lighttpd
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Lighttpd
Lighttpd
Lighttpd
View on Wikipedia
from Wikipedia
lighttpd
Original authorJan Kneschke
Initial releaseMarch 2003; 22 years ago (2003-03)
Stable release
1.4.82[1] Edit this on Wikidata / 12 September 2025; 4 months ago (12 September 2025)
Preview release1.4.82 (September 12, 2025; 4 months ago (2025-09-12)) [±]
Written inC
Available inEnglish
TypeWeb server
LicenseBSD-3-Clause
Websitewww.lighttpd.net Edit this on Wikidata
Repository

lighttpd (prescribed pronunciation: "lighty")[2] is an open-source web server optimized for speed-critical environments. It was originally written by Jan Kneschke as a proof-of-concept of the c10k problem – how to handle 10,000 connections in parallel on one server,[3] but has gained worldwide popularity.[4] Its name is a portmanteau of "light" and "httpd".

Premise

[edit]

The low memory footprint (compared to other web servers),[5] small CPU load and speed optimizations[6] make lighttpd suitable for servers that are suffering load problems, or for serving static media separately from dynamic content. lighttpd is free and open-source software and is distributed under the BSD license. It runs natively on Unix-like operating systems, with experimental support for Microsoft Windows.[7]

Application support

[edit]

lighttpd supports the FastCGI, SCGI and CGI interfaces to external programs, allowing web applications written in any programming language to be used with the server. As a particularly popular language, PHP performance has received special attention. Lighttpd's FastCGI can be configured to support PHP with opcode caches (like APC) properly and efficiently. Additionally, it has received attention from its popularity within the Python, Perl, Ruby and Lua communities. Lighttpd also supports WebDNA, the resilient in-memory database system designed to build database-driven websites. It is a popular web server for the Catalyst and Ruby on Rails web frameworks. Lighttpd does not support ISAPI.

Features

[edit]

Limitations

[edit]
  • Versions below 1.4.40 do not officially support sending large files from CGI, FastCGI, or proxies[14] unless X-Sendfile is used. This limitation has been removed in lighttpd 1.4.40.[15]
  • No HTTP/3 support

Usage

[edit]

Lighttpd was used in the past by several high-traffic websites, including Bloglines, xkcd, Meebo, and YouTube.[16][better source needed] The Wikimedia Foundation also once ran Lighttpd servers.[17] Due to relatively small size it's often used in embedded devices like GL.iNet and Turris Omnia.

It's also used by git as a HTTP server daemon.

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Lighttpd

View on Grokipedia
from Grokipedia
lighttpd (pronounced lighty) is a free and open-source software designed for high performance, security, standards compliance, and flexibility, particularly optimized for environments requiring efficient use of memory and CPU resources. Developed by Jan Kneschke in February 2003 as a proof-of-concept to address the —handling up to 10,000 concurrent connections on a single server—lighttpd quickly evolved to include features like support and load balancing within its early weeks of development. Its enables it to outperform traditional process-based servers like in high-load scenarios, making it suitable for both small embedded systems and large-scale deployments. Key features include support for , CGI, authentication, output compression, URL rewriting, and modular extensions that allow customization without compromising speed. Released under the revised BSD license, lighttpd remains actively maintained, with the latest stable version, 1.4.82, released on September 12, 2025, incorporating enhancements such as restricted request trailers and improved mod_mbedtls support for security. Historically, it powered prominent sites including , , and , demonstrating its for demanding applications. As of November 2025, it holds a share of less than 0.1% among web servers, favored in resource-constrained or performance-critical setups.

Introduction

Overview

lighttpd (pronounced "lighty," a portmanteau of "light" and "") is an open-source written , designed as an asynchronous-capable HTTP daemon optimized for high-performance environments with low resource consumption in terms of CPU and memory usage. It emphasizes security, speed, compliance with web standards, and flexibility, making it suitable for serving static content, dynamic applications, and embedded systems across various scales. Released under the revised BSD license, lighttpd allows broad redistribution and modification while requiring preservation of notices. The current stable version is 1.4.82, released on September 12, 2025. lighttpd primarily supports operating systems such as , BSD variants, and Solaris, where it leverages native event handling mechanisms. Experimental support for Windows is available through , enabling nearly full feature parity with deployments. Its enables efficient handling of thousands of simultaneous connections without blocking, supporting operations.

History

lighttpd was created by Jan Kneschke in February 2003 as a proof-of-concept web server designed to efficiently handle high loads and address resource constraints in high-traffic scenarios, particularly inspired by the needs of embedded systems and dynamic content serving environments. The project originated from Kneschke's efforts to solve the c10k problem—managing 10,000 simultaneous connections on a single server without excessive resource consumption—drawing from observations of traditional servers like Apache struggling under similar conditions. From its inception, lighttpd has been released under the revised BSD license, emphasizing open-source accessibility and flexibility for various deployment needs. The first public release occurred in 2003, quickly followed by version 1.0 in 2004, which stabilized core functionality for broader adoption. Key milestones in the mid-2000s included the launch of the 1.4 series in 2005, introducing significant improvements to support for better handling of dynamic applications and load balancing. In the , development shifted toward enhanced collaboration, with the project adopting for version control around 2013 to facilitate community contributions, alongside the established platform at redmine.lighttpd.net. Ongoing maintenance has seen active involvement from key contributors, including original author Jan Kneschke and current lead maintainers Stefan Bühler and Glenn Strauss, who oversee bug fixes, security enhancements, and feature updates through community-driven efforts. The most recent milestone, version 1.4.82 released on September 12, 2025, addressed critical security issues related to request trailers, underscoring the project's commitment to compliance and stability. Throughout its history, lighttpd has maintained its revised BSD licensing, enabling widespread integration in performance-critical setups.

Technical Aspects

Architecture

lighttpd employs an event-driven, single-process designed to handle a high volume of concurrent connections efficiently without spawning threads or processes per connection. This approach relies on non-blocking I/O operations and system-level I/O multiplexing mechanisms such as select(), poll(), on , or on BSD systems, allowing the server to monitor multiple file descriptors simultaneously for readiness without blocking the main . The server utilizes a modular plugin system where extensions are implemented as shared libraries (e.g., .so files) that are loaded dynamically at startup based on the configuration file's server.modules directive, enabling functionality additions without recompiling the core binary. in lighttpd is optimized through the use of chunk pools in the chunkqueue structure, which provides efficient buffer allocation and reuse to minimize overhead, alongside techniques like the sendfile() for serving static files directly from disk to the network socket. Request handling follows a non-blocking : incoming HTTP requests are parsed in the event loop, processed through a sequence of loaded modules acting as filters for tasks such as or , and responses are generated and queued for asynchronous transmission without halting other operations. lighttpd natively supports both IPv4 and protocols via configuration options like server.use-ipv6, with SSL/TLS handled through dedicated modules such as mod_openssl or mod_mbedtls. As of version 1.4.82 (September 2025), mod_mbedtls includes improvements such as support for psa_crypto_init() when using MBEDTLS_USE_PSA_CRYPTO.

Features

lighttpd offers comprehensive support for HTTP/1.1 and protocols, with the latter enabling multiplexing for concurrent request handling over a single connection. support was introduced in version 1.4.56 (November 2020) and is enabled by default since version 1.4.59. For dynamic content generation, it natively integrates CGI for executing scripts directly, for persistent backend processes, and SCGI for lightweight application server communication, commonly used with languages such as , Python, and . Security capabilities include built-in HTTP Basic and Digest authentication compliant with RFC 7617 and RFC 7616, respectively, granular access controls via IP-based restrictions, and anti-DoS protections through configurable connection limits per IP and overall server capacity. As of version 1.4.82 (September 2025), request trailers are restricted unless explicitly allowed via configuration, enhancing security against malformed requests. Content optimization is facilitated by URL rewriting to manipulate request paths dynamically, gzip compression for reducing response sizes, range requests for serving partial file downloads as per HTTP/1.1 specifications, and to manage multiple domains on a single server instance. Other utilities encompass Server-Side Includes (SSI) for embedding dynamic elements in static pages, customizable directory listings to expose file structures securely, and basic caching mechanisms like stat-cache for accelerating file metadata lookups. lighttpd adheres fully to HTTP RFC standards, such as those defining protocol semantics and , while incorporating extensions to meet evolving web demands like upgrades over HTTP/2. Core features can be extended via modules for specialized requirements.

Configuration and Customization

Core Configuration

The configuration of lighttpd is defined in a , typically named lighttpd.conf, which employs a simple, C-like syntax for specifying server behavior. This syntax supports key-value pairs such as name = value for assignments, name += value for appending to arrays or strings, and name := value for replacing existing values (introduced in version 1.4.46). Values can be strings (enclosed in quotes), integers, booleans (enable or disable), or arrays (enclosed in parentheses). Configuration blocks allow for server-wide settings and conditional logic, enabling dynamic adjustments based on conditions like the HTTP host header using directives such as $HTTP["host"] =~ "example.org" { ... }. Essential directives establish the server's basic operation. The server.document-root directive specifies the root directory from which static files are served, for example, server.document-root = "/var/www". The server.port sets the listening port, defaulting to 80 for HTTP, as in server.port = 80. To control the network interface, server.bind defines the IP address or to bind to, such as server.bind = "127.0.0.1" for local access only. Module loading is managed via server.modules, an array listing required plugins, e.g., server.modules = ("mod_accesslog", "mod_staticfile"). Logging is configured through dedicated options for monitoring and . The server.errorlog (or errorlog-file) directive points to the error log file, like server.errorlog = "/var/log/lighttpd/error.log", capturing server errors and startup issues. Access logging, handled by the accesslog module, uses accesslog.filename to specify the log path, for instance, accesslog.filename = "/var/log/lighttpd/access.log", recording client requests for auditing. Basic security and error handling are addressed with core directives. The server.error-handler-404 allows customization of 404 responses by redirecting to a specific URI, such as server.error-handler-404 = "/error404.html", for non-dynamic requests. MIME types are assigned using mimetype.assign, an array mapping file extensions to content types, e.g., mimetype.assign = ( ".html" => "text/html", ".css" => "text/css" ), ensuring proper client interpretation and mitigating type-related vulnerabilities. As of version 1.4.82, security can be further enhanced by restricting HTTP request trailers using the server.feature-flags directive, for example, server.feature-flags += ( "request.trailer-whitelist" => "header1,header2" ), which limits trailers to a comma-separated list of allowed field names to prevent abuse. A typical configuration file structure begins with global settings, followed by conditional blocks for . For example:

server.modules = ( "mod_accesslog", "mod_staticfile" ) server.document-root = "/var/www" server.port = 80 server.errorlog = "/var/log/lighttpd/error.log" mimetype.assign = ( ".html" => "text/html" ) $HTTP["host"] =~ "example.org" { server.document-root = "/var/www/example.org" accesslog.filename = "/var/log/lighttpd/example.org.log" }

server.modules = ( "mod_accesslog", "mod_staticfile" ) server.document-root = "/var/www" server.port = 80 server.errorlog = "/var/log/lighttpd/error.log" mimetype.assign = ( ".html" => "text/html" ) $HTTP["host"] =~ "example.org" { server.document-root = "/var/www/example.org" accesslog.filename = "/var/log/lighttpd/example.org.log" }

This setup serves content from /var/www by default and overrides it for requests to example.org, with host-specific .

Modules and Extensions

Lighttpd's extensibility relies on a modular architecture where additional functionality is provided through loadable plugins, primarily implemented as shared object (.so) files located in the directory specified by the server.modules-path configuration directive, typically /usr/lib/lighttpd or similar system-specific paths. Modules are loaded dynamically at startup via the server.modules array in the , which lists module names in the order of execution; this sequence determines how requests are processed, with and modules placed early, dynamic handlers in the middle, and modules last. Only necessary modules should be loaded to optimize and usage. Certain core modules are automatically loaded without explicit configuration, providing essential features for basic operation: mod_indexfile for directory index generation, mod_dirlisting for automatic directory listings, and mod_staticfile for serving static content. Optional modules, which must be explicitly included in server.modules, extend capabilities for common tasks; examples include mod_access for IP-based , mod_alias for URL aliasing and redirects, mod_deflate for content compression using (replacing the deprecated mod_compress), and mod_fastcgi for interfacing with dynamic backends like scripts. Other widely used optional modules are mod_proxy for reverse proxying to upstream servers, mod_rewrite for URL rewriting based on regular expressions, mod_ssl (or mod_openssl) for enabling with TLS/SSL termination, mod_magnet for scripting to handle requests programmatically, mod_webdav for support implementing RFC 4918, and mod_h2 for protocol support (introduced in 1.4.56 and separated as a distinct module in 1.4.71). Third-party extensions, often contributed by the community, provide specialized integrations not included in the core distribution; notable examples include caching with implementations like mod_memcache for session storage and content acceleration. These extensions are typically compiled separately and loaded similarly to official modules, though compatibility with specific lighttpd versions should be verified. Configuration of modules involves module-specific directives within the lighttpd.conf file or included files. For instance, mod_fastcgi uses the fastcgi.server directive to define backend pools, such as:

fastcgi.server = ( ".php" => (( "host" => "127.0.0.1", "port" => 9000, "bin-path" => "/usr/bin/[php](/page/PHP)-cgi", "max-procs" => 1, "bin-environment" => ( "PHP_FCGI_CHILDREN" => "4", "PHP_FCGI_MAX_REQUESTS" => "10000" ) )) )

fastcgi.server = ( ".php" => (( "host" => "127.0.0.1", "port" => 9000, "bin-path" => "/usr/bin/[php](/page/PHP)-cgi", "max-procs" => 1, "bin-environment" => ( "PHP_FCGI_CHILDREN" => "4", "PHP_FCGI_MAX_REQUESTS" => "10000" ) )) )

This setup spawns a process pool on 9000, balancing load across child processes. Similarly, mod_proxy employs proxy.server for upstream definitions, as in:

$HTTP["host"] == "example.com" { proxy.server = ( "" => (( "host" => "10.0.0.10", "port" => 80 )) ) }

$HTTP["host"] == "example.com" { proxy.server = ( "" => (( "host" => "10.0.0.10", "port" => 80 )) ) }

Here, requests to example.com are forwarded to an internal server at 10.0.0.10:80, supporting features like load balancing with proxy.balance = "round-robin". In the 1.4.x series, module enhancements have included support via the mod_h2 module (since version 1.4.71), improving multiplexing and performance, alongside updates to mod_fastcgi for better process management and mod_proxy for interactions in version 1.4.70.

Performance and Limitations

Performance Characteristics

Lighttpd exhibits a low resource footprint, making it suitable for resource-constrained environments. Basic setups typically consume less than 1 MB of RAM, with additional usage of approximately 100 KB for every 4,000 increase in file descriptors beyond the default. It scales efficiently to handle over 10,000 concurrent connections on modest hardware. In benchmarks, lighttpd demonstrates strong performance for static file serving. For instance, on a single-core Debian 12 virtual machine with 2 GB RAM, it achieved 8,645 requests per second (RPS) for static content, outperforming Apache in the same test conditions. Under high concurrency (1,000 connections), it maintained 7,936 RPS with an average latency of 265.8 ms and 55% CPU utilization. Earlier tests on Ubuntu hardware showed lighttpd serving static CSS files at 1,462 RPS, roughly twice the rate of Apache's 777 RPS without keep-alive. Lighttpd's efficiency stems from its single-process, , which leverages operating system-specific handlers like on for non-blocking I/O. For dynamic content, it employs selective process forking through modules like mod_fastcgi, minimizing overhead compared to threaded models. Recent versions support tunable options such as thread pools in I/O backends (e.g., gthread-aio) to optimize disk-bound workloads. Version 1.4.82 includes optimizations like avoiding chunk memory reallocation on read/recv to enhance performance. Compared to other servers, lighttpd excels in static and embedded scenarios due to its design, often using less memory than or under similar loads. It remains competitive with for reverse proxying but offers a smaller overall footprint, making it preferable for high-load, low-resource setups. Key tuning strategies include setting server.max-connections to match expected traffic (e.g., 16 for low-memory systems or 4,096+ for high throughput) and enabling via server.event-handler = "epoll" on to maximize connection handling. Adjusting server.max-fds to 16,384 or higher, combined with OS limits like ulimit -n 65536, further enhances scalability under load.

Known Limitations

As of version 1.4.82, lighttpd lacks native support for over , necessitating the use of external reverse proxies such as to handle such traffic. Versions of lighttpd prior to 1.4.40 exhibited limitations in handling large files through CGI, , or proxy backends, as the server did not fully support asynchronous streaming without workarounds like X-Sendfile; this issue was addressed in 1.4.40 with bidirectional streaming to dynamic backends, though performance remains dependent on the backend implementation. lighttpd does not provide built-in support for ISAPI extensions, which are specific to Windows environments, nor does it natively process .htaccess files for per-directory configurations, requiring all equivalents to be defined explicitly in the main server . Historically, lighttpd has faced vulnerabilities, including stack-based buffer overflows in the mod_extforward plugin affecting versions 1.4.46 through 1.4.63 (CVE-2022-22707), as well as earlier issues like heap overflows in version 1.4.15; the maintains a focus on timely patches through regular stable releases to mitigate such risks. Recent releases, including 1.4.82, provide fixes such as logic corrections in mod_mbedtls PSA crypto initialization. The experimental Windows port of lighttpd does not achieve full feature parity with its Unix counterparts, omitting certain modules and optimizations tailored to non-Windows platforms. Additionally, lighttpd offers no native clustering or load-balancing capabilities, relying on external tools for distributed deployments. Common workarounds include configuring mod_proxy to forward requests to a supporting proxy like , or integrating lighttpd in hybrid setups with for complementary functionality. These limitations can impact overall in scenarios requiring advanced protocol support or , as detailed in performance analyses.

Deployment and Usage

Installation Methods

Lighttpd can be installed on various operating systems using native package managers, which provide pre-compiled binaries and handle dependencies automatically. On and systems, the server is available in the official repositories and can be installed with the command sudo apt install lighttpd. For (RHEL), , and derivatives, use sudo dnf install lighttpd (or sudo yum install lighttpd on older versions). On macOS, Homebrew users can install it via brew install lighttpd, which places binaries in /usr/local/bin and configuration in /usr/local/etc/lighttpd. For systems without suitable packages or for custom builds, lighttpd can be compiled from source. Download the latest stable release, such as version 1.4.82, from https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.82.tar.xz, or clone the repository with git clone https://git.lighttpd.net/lighttpd/lighttpd1.4.git. Required dependencies include pkg-config, libpcre (PCRE development libraries), autoconf, automake, and libtool; on Debian-based systems, these can be installed with sudo apt-get build-dep lighttpd. To build, run ./autogen.sh (for git clones), followed by ./configure --prefix=/usr/local, make, make check, and sudo make install. In containerized or embedded environments, lighttpd supports integration with tools like Docker, where community-maintained images such as sebp/lighttpd are available on Docker Hub for quick deployment. For IoT and embedded distributions, it integrates with via opkg install lighttpd for lightweight web serving, and with through layers by adding lighttpd to the image recipe. After installation via packages, the default is located at /etc/lighttpd/lighttpd.conf, while source builds use /usr/local/etc/lighttpd/lighttpd.conf. Service management is handled by init scripts: on systemd-based systems (most modern distributions), use systemctl enable --now lighttpd.service to start and enable the service; on SysV init systems, employ service lighttpd start. To manage versions, upgrade to the latest release like 1.4.82 by reinstalling via package managers or rebuilding from source, always reviewing the for potential breaking changes, such as modifications to request handling behaviors.

Common Applications

Lighttpd excels in serving static content, such as , CSS, , images, and videos, due to its that efficiently manages file I/O and concurrent connections with minimal CPU and memory overhead. This makes it particularly suitable for high-traffic sites focused on static assets, including documentation hosts where rapid delivery of unchanging files is essential. The default mod_staticfile module handles this natively, allowing straightforward configuration for directories containing primarily static resources without additional processing overhead. For dynamic content, lighttpd commonly integrates with backends via , pairing effectively with PHP-FPM to process PHP scripts in applications like content management systems. The mod_fastcgi module spawns and manages processes, supporting options like child process limits and maximum requests per process to optimize performance. Similarly, it supports for Python applications, including Django frameworks, by routing requests through the uWSGI protocol for efficient dynamic script execution. Lighttpd frequently operates as a , forwarding requests to upstream servers while providing load balancing to distribute traffic across multiple backends, such as instances or application servers. Using the mod_proxy module, it employs strategies like round-robin or least-connection balancing to enhance and in clustered environments. In embedded and IoT contexts, lighttpd's lightweight footprint—requiring under 1 MB of RAM—enables its use in resource-limited devices, such as routers with firmware for serving web management interfaces. It is also deployed in media players and smart devices to handle static file delivery and basic HTTP services without straining hardware constraints. During development, lighttpd provides a simple local server for testing web applications, configurable via minimal setup files to mimic production static and dynamic serving. It further acts as a backend for Git's smart protocol, enabling repository cloning, pushing, and pulling over HTTP using the git-http-backend CGI script.

Notable Deployments

Lighttpd gained early prominence through its adoption by high-traffic websites for serving static content and media. utilized lighttpd as an off-load server for static assets, such as video thumbnails, during its initial growth phase, with documented usage as early as 2007 on subdomains like sjl-static16.sjl.youtube.com running lighttpd version 1.4.11.8. The integrated lighttpd into its infrastructure for resource-intensive tasks, including image hosting and resizing on upload.wikimedia.org (using version 1.4.13 in 2007) and distributing large SQL dumps exceeding 4 GB on download.wikimedia.org. These deployments highlighted lighttpd's ability to manage high-volume static file delivery, allowing primary servers to focus on dynamic content processing. , a platform, also relied on lighttpd's high-speed I/O infrastructure to scale effectively under load. As of November 2025, lighttpd powers less than 0.1% of websites with known web servers, reflecting a decline from its higher adoption rates in the amid the rise of competitors like , though it remains steady in specialized niches such as content delivery networks (CDNs), gateways, and online forums. In embedded systems, lighttpd serves as the web interface for devices like GL.iNet routers, where its lightweight footprint enables efficient configuration management via lighttpd.conf. The Turris Omnia router similarly uses lighttpd for its LuCI web administration panel and supports extensions like integration for secure access. Some deployments demonstrate lighttpd's scalability in handling vast data volumes, such as in setups where it proxies access to petabyte-scale repositories. The community-maintained PoweredByLighttpd compiles user-submitted examples of such implementations, showcasing its ongoing use across diverse environments from personal projects to enterprise offloading.

References

  1. https://www.lighttpd.net/
  2. https://www.lighttpd.net/story/
  3. https://w3techs.com/technologies/details/ws-lighttpd
  4. https://wiki.alpinelinux.org/wiki/Lighttpd
  5. https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/COPYING
  6. https://www.lighttpd.net/releases/
  7. https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_62
  8. https://www.opencsw.org/package/lighttpd/
  9. https://redmine.lighttpd.net/projects/lighttpd/wiki/DevelWin32
  10. https://www.elegantthemes.com/blog/wordpress/lighttpd-web-server
  11. https://www.hostingadvice.com/blog/lighttpd-offers-free-open-source-web-server-software/
  12. https://www.plesk.com/blog/various/top-web-servers-for-linux-and-windows/
  13. https://blog.lighttpd.net/articles/2005/11/23/lighttpd-1-4-8-and-multiple-rails-apps/
  14. https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_10
  15. https://github.com/lighttpd/lighttpd1.4
  16. https://redmine.lighttpd.net/projects/lighttpd/wiki
  17. https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_82
  18. https://redmine.lighttpd.net/projects/1/wiki/Server_event-handlerDetails
  19. https://wiki.debian.org/Lighttpd
  20. https://redmine.lighttpd.net/projects/1/wiki/docs_configurationoptions
  21. https://stackoverflow.com/questions/37077497/how-to-compile-lighttpd-modules-statically
  22. https://www.lighttpd.net/2018/11/28/1.4.52/
  23. https://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads/
  24. https://redmine.lighttpd.net/projects/lighttpd/wiki/IPv6-Config
  25. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL
  26. https://redmine.lighttpd.net/projects/1/wiki/Docs_ModProxy
  27. https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_feature-flagsDetails
  28. https://redmine.lighttpd.net/projects/1/wiki/frequentlyaskedquestions
  29. https://www.cyberciti.biz/tips/lighttpd-set-throughput-connections-per-ip.html
  30. https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_dirlisting
  31. https://redmine.lighttpd.net/projects/lighttpd/wiki/WebSockets
  32. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Configuration
  33. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ConfigurationOptions
  34. https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_modulesDetails
  35. https://serverfault.com/questions/135583/setting-module-path-in-lighttpd-config-file
  36. https://redmine.lighttpd.net/projects/lighttpd/wiki/Doc_mod_magnet
  37. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModWebDAV
  38. https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_71
  39. https://redmine.lighttpd.net/projects/1/wiki/Docs_ModMemCache
  40. https://www.lighttpd.net/2023/5/10/1.4.70/
  41. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_Performance
  42. https://www.site24x7.com/learn/how-to-deploy-and-configure-lighttpd.html
  43. https://gitlab.nic.cz/turris/os/packages/-/issues/665
  44. https://linuxconfig.org/ultimate-web-server-benchmark-apache-nginx-litespeed-openlitespeed-caddy-lighttpd-compared
  45. https://paul.annesley.cc/2006/12/static-content-twice-the-speed-with-lighttpd/
  46. https://www.lighttpd.net/benchmark/
  47. https://serverfault.com/questions/72058/what-are-the-advantages-of-lighttpd-over-apache
  48. https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_80
  49. https://www.lighttpd.net/2016/7/16/1.4.40/
  50. https://nvd.nist.gov/vuln/detail/CVE-2022-22707
  51. https://www.exploit-db.com/exploits/30322
  52. https://redmine.lighttpd.net/projects/lighttpd/wiki/GetLighttpd
  53. https://formulae.brew.sh/formula/lighttpd
  54. https://download.lighttpd.net/lighttpd/
  55. https://redmine.lighttpd.net/projects/lighttpd/wiki/InstallFromSource
  56. https://hub.docker.com/r/sebp/lighttpd
  57. https://openwrt.org/docs/guide-user/services/webserver/lamp
  58. http://layers.openembedded.org/layerindex/recipe/53823/
  59. https://www.cyberciti.biz/faq/stop-lighttpd-server/
  60. https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModStaticFile
  61. https://uwsgi-docs.readthedocs.io/en/latest/Lighttpd.html
  62. https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_proxy
  63. https://redmine.lighttpd.net/projects/1/wiki/TutorialConfiguration
  64. https://redmine.lighttpd.net/projects/lighttpd/wiki/How_to_set_up_a_git_server_over_http%28s%29
  65. https://forum.gl-inet.com/t/network-mode-access-point-web-server-via-ipv6/15541
  66. https://wiki.turris.cz/en/public/letencrypt_turris_lighttpd_simple
  67. https://hoop.dev/blog/the-simplest-way-to-make-lighttpd-minio-work-like-it-should/
  68. https://redmine.lighttpd.net/projects/1/wiki/poweredbylighttpd
Add your contribution
Related Hubs
User Avatar
No comments yet.