index.md (3487B)
1  2 3 quark is an extremely small and simple HTTP GET/HEAD-only web server for static 4 content. 5 6 The goal of this project is to do one thing and do it well, namely serving 7 static web directories and doing that right. Most other solutions either are 8 too complex (CGI support, dependencies on external libraries, ...) or lack 9 features you expect (TLS, virtual hosts, partial content, not modified since, 10 ...). quark tries to find a midway and just restrict itself to being static 11 while still offering functions you only find in more bloated solutions and 12 being as secure as possible (chroot, privilege dropping, strict parsers, no 13 malloc at runtime, pledge, unveil, ...). 14 15 Static web 16 ---------- 17 We believe that most of the web does not need to be dynamic and increasing 18 complexity on server-side applications is one of the main reasons for the web 19 obesity crisis. The common approach nowadays is to do everything on the server, 20 including parsing requests, modifying files and databases, generating HTML and 21 all that using unfit languages like PHP or JavaScript, which is a security and 22 efficiency nightmare. 23 24 Over the years we have seen massive amounts of security holes in numerous 25 applications of tools commonly used for these jobs (PHP, node.js, 26 CGI-implementations, ...). The reason why we are in this situation in the first 27 place is due to the fact that the jobs of data processing and data 28 presentation, which should be separate, converged together into one. 29 30 The solution is to rely on static regeneration independent from the web server, 31 which just serves static files. You can still implement e.g. form handlers for 32 dynamic content which run as their own network instance and operate 33 independently from the web server. What's left is just to generate the static 34 content using the database and repeating this process in case the database is 35 updated. 36 37 This way the jobs of data processing and data presentation are separate again, 38 with many advantages. All requests are handled with constantly low latency, 39 with the possibility of serving everything directly from RAM (using a ramfs). 40 Separated concerns make it very unattractive to attack the web server itself 41 and the attack surface that is left, if it is present at all, is the separate 42 form handler, which can be implemented in a very simple, safe and efficient 43 manner. 44 45 In case there is an attack on this infrastructure and the attacker manages to 46 DoS the form handler, the serving of content is still unaffected. 47 48 TLS-support 49 ----------- 50 quark does not natively support TLS. A more suckless approach than to 51 implement TLS into it is to use a TLS reverse proxy (e.g. [tlstunnel](https://github.com/hannesm/tlstunnel), 52 [hitch](https://hitch-tls.org/) or [stunnel](https://www.stunnel.org/)). 53 It accepts encrypted TLS connections and forwards them as unencrypted 54 requests to a server. In this case, one can run such a reverse proxy to listen 55 on a public IP address and forward the requests to a local port or UNIX-domain socket. 56 57 Solutions 58 --------- 59 * [saait](https://git.codemadness.org/saait/file/README.html) site generator 60 * [stagit](https://git.codemadness.org/stagit/file/README.html) git page generator 61 62 Development 63 ----------- 64 You can [browse](//git.suckless.org/quark) the source code repository or get a 65 copy with the following command: 66 67 git clone https://git.suckless.org/quark 68 69 Author 70 ------ 71 * Laslo Hunhold (dev@frign.de) 72 73 Please contact me when you find information that could be added to this page.