[wiki] [sites] Update quark page with thoughts on the static web || Laslo Hunhold

From: <git_AT_suckless.org>
Date: Sun, 25 Feb 2018 12:09:26 +0100

commit a39a8f110b173be8189a8d575fcc1c66f7a9b9ef
Author: Laslo Hunhold <dev_AT_frign.de>
Date: Sun Feb 25 12:09:07 2018 +0100

    Update quark page with thoughts on the static web

diff --git a/tools.suckless.org/quark/index.md b/tools.suckless.org/quark/index.md
index e0883d4e..f1236c5f 100644
--- a/tools.suckless.org/quark/index.md
+++ b/tools.suckless.org/quark/index.md
_AT_@ -1,7 +1,56 @@
-quark is an extremely small and simple HTTP GET-only web server. It only serves
-static pages on a single host.
+quark is an extremely small and simple HTTP GET/HEAD-only web server.
+The goal of this project is to do one thing and do it well, namely serving
+static web directories and doing that right. Most other solutions either
+are too complex (CGI support, dependencies on external libraries, ...) or
+lack features you expect (TLS, virtual hosts, partial content, not modified
+since, ...). quark tries to find a midway and just restrict itself to being
+static while still offering functions you only find in more bloated solutions
+and being as secure as possible (chroot, privilege dropping, strict parsers,
+no malloc at runtime, pledge, ...).
+Static web
+We believe that most of the web does not need to be dynamic and increasing
+complexity on server-side applications is one of the main reasons for the
+web obesity crisis.
+The common approach nowadays is to do everything on the server, including
+parsing requests, modifying files and databases, generating HTML and all
+that using unfit languages like PHP or JavaScript, which is a security and
+efficiency nightmare.
+Over the years we have seen massive amounts of security holes in numerous
+applications of tools commonly used for these jobs
+(PHP, node.js, CGI-implementations, ...).
+The reason why we are in this situation in the first place is due to the fact that
+the jobs of data processing and data presentation, which should be separate,
+converged together into one.
+The solution is to rely on static regeneration independent from the web server,
+which just serves static files. You can still implement e.g. form handlers for
+dynamic content which run as their own network instance and operate independently
+from the web server.
+What's left is just to generate the static content using the database and repeating
+this process in case the database is updated.
+This way the jobs of data processing and data presentation are separate again,
+with many advantages. All requests are handled with constantly low latency, with
+the possibility of serving everything directly from RAM (using a ramfs). Separated
+concerns make it very unattractive to attack the web server itself and the
+attack surface that is left, if it is present at all, is the separate form handler,
+which can be implemented in a very simple, safe and efficient manner.
+In case there is an attack on this infrastructure and the attacker manages to
+DoS the form handler, the serving of content is still unaffected.
+* [saait](http://git.codemadness.nl/saait/log.html) site generator
+* [stagit](http://git.codemadness.nl/stagit/log.html) git page generator
_AT_@ -11,3 +60,10 @@ get a copy with the following command:
         git clone git://git.suckless.org/quark
+* Laslo Hunhold (dev_AT_frign.de)
+Please contact me when you find information that could be added to this
Received on Sun Feb 25 2018 - 12:09:26 CET

This archive was generated by hypermail 2.3.0 : Sun Feb 25 2018 - 12:12:21 CET