Unnamed repository; edit this file 'description' to name the repository.
Log | Files | Refs

commit a39a8f110b173be8189a8d575fcc1c66f7a9b9ef
parent a12a226e9286319f819f657dbe0a8cd04cd353a0
Author: Laslo Hunhold <>
Date:   Sun, 25 Feb 2018 12:09:07 +0100

Update quark page with thoughts on the static web

Diffstat: | 60++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/ b/ @@ -1,7 +1,56 @@ ![quark](quark.svg) -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. + +Solutions +--------- + +* [saait]( site generator +* [stagit]( git page generator Development ----------- @@ -11,3 +60,10 @@ get a copy with the following command: git clone git:// +Author +------ + +* Laslo Hunhold ( + +Please contact me when you find information that could be added to this +page.