From: Lucian Mogosanu Date: Thu, 13 Jun 2019 19:18:26 +0000 (+0300) Subject: posts: 093 X-Git-Tag: v0.11~47 X-Git-Url: https://git.mogosanu.ro/?a=commitdiff_plain;h=60590d708dc73eb2fbe48fe4df3ab5ff4afad134;p=thetarpit.git posts: 093 --- diff --git a/drafts/000-hunchentoot-i.markdown b/drafts/000-hunchentoot-i.markdown deleted file mode 100644 index 6d7a37b..0000000 --- a/drafts/000-hunchentoot-i.markdown +++ /dev/null @@ -1,115 +0,0 @@ ---- -postid: 000 -title: A review of Hunchentoot's code history -date: June 11, 2019 -author: Lucian Mogoșanu -tags: tech, tmsr ---- - -This post is part of a series on [Common Lisp WWWism][cl-www]. Before -continuing, please read [prior discussions][cl-www] on the subject. - -As mentioned in an [older study][development-log-i] (admittedly, a -more superficial one) of Common Lisp web servers, -[Hunchentoot][hunchentoot] is a monster with many tendrils -- in -truth, one of the very few CL-based HTTP servers used in production -nowadays. On the surface it weighs about six to seven thousand lines -of code, depending on whether we count the comments. In depth it -exposes a complex architecture, with support for e.g. cookies and -sessions and other usefuls, but most importantly, its interface offers -a ton of flexibility in handling requests and distributing -workloads. - -I've previously found this to be too much for my needs and thus went -for [something simpler][development-log-ii], at least on the -surface. However, following [feedback][btcbase-1911356] and [further -discussion][btcbase-1911437], and in light of the Republican need for -a proper HTTP server, I have decided to review what CL has on offer, -and more precisely to have another good look at Hunchentoot. - -This sounded easy enough at the beginning, especially that it wasn't -the first time. Only a Hunchentoot genesis would need to start -*somewhere*, and the problem is there are no less than 111 somewheres -to start from if we're to count the so-called "versions" in the -CHANGELOG file, and almost 600 patches, that is, also "versions", -although for some unknown reason those are thought of as something -else by the original authors. Having realized this, I did two things: -firstly, I [asked][btcbase-1916132] for input from Hunchentoot users -in the WoT; and secondly, I put my hazmat suit on and took a walk -through the depths of Hunchentoot history, to inform my future -decisions. - -Below lies (with bullets!) the result of this documentation, in the -form of a summary that groups changes into various categories, -e.g. bugfixing, robustness, API changes etc. Looking at the changelog -in chronological order, we see: - -* Version 0.4.0: First version that comes with SBCL support (among - others). Changes up until then have to do mostly with stability and - small features, e.g. chunked encoding, keepalive. -* Versions 0.4.x: Mostly bug fixing, e.g. in mod_lisp, some SSLism. -* Versions 0.5.x: RAW-POST-DATA behaviour changes, added flexibility. -* Versions 0.6.x: Bugs, robustness. -* Versions 0.7.x: Support compilation without SSL; support Win32. -* Versions 0.8.x: Robustness, bugfixing. -* Versions 0.9.x: More Allegro/SBCL/etc. support; more interface - flexibility. -* Versions 0.{10-14}.x: Debugging support, bugfixing, robustness. -* Versions 0.15.x: CLISP support; added CL-FAD as dependency; - bugfixing, small interface changes. -* Version 1.0.0: Architectural redesign, small fixes, improvements. -* Versions 1.1.x: Architectural changes, bugfixes, shawarma, e.g.: - "safeguard measures against XSS attacks". Why does JavaScript sanity - need to be encoded in the *implementation* of a HTTP server anyway? - -Version 1.2 is where development on [GitHub][github] begins and code -changes can be examined. Versions prior to 1.2.0 seem to have been -lost. - -* Versions 1.2.{0-9}: Many bugfixes, documentation updates; also - SSLism, support for non-SSL mode, portability, cookie handling, - multithreading. -* Versions 1.2.{10-16}: Functionality to get local address and port; - also, bugfixes, documentation. -* Versions 1.2.{17-24}: Multithreading API changes; also, bugfixes, - portability, documentation; support is added for new mimetype -- why - does the list of mimetypes need to be part of the *code* and not a - config parameter?; also, robustness, code sanity. -* Versions 1.2.{25,26}: HTTP header handling; SSLism, code sanity. -* Versions 1.2.{27,28}: Documentation updates, bugfixing, code - cleanup, IPv6 support, other new functionality, robustness. -* Version 1.2.29: Revert IPv6 changes. -* Versions 1.2.{30-38}: Robustness, bugfixing, documentation, support - for "additional HTTP status codes" (RFC 6585), multithreading - optimizations, support for ports allocated by system. Phf [is - using][btcbase-1916277] version 1.2.35 for [btcbase][btcbase], which - makes this the likeliest starting point for a genesis. - -Beyond version 1.2.38, Hunchentoot seems to have "gone agile". This -includes SSLism changes, reintroduced support for IPv6 which seems to -bump up the required usocket version and other potential -breakages. Thus, I'm not going to look further in that direction. - -As a side note, it seems that [my hunch][tmsr-delay] was not at all -unfounded: although I have given myself [ample time][btcbase-1914648] -to look at this, it still hasn't been enough, and here I am, about -halfway through the work. As a side note to the side note: although I -expect to genesize a working item, I expect it to be [not at all -pretty][btcbase-1829442], and full of warts etc., although in -principle -- *in principle* -- it should be fairly easy to cut -e.g. [SSLism][no-ssl] out. - -[cl-www]: /posts/y05/090-tmsr-work-ii.html#selection-108.0-108.17 -[development-log-i]: /posts/y03/05c-development-log-i.html#selection-187.0-192.0 -[hunchentoot]: https://edicl.github.io/hunchentoot/ -[development-log-ii]: /posts/y03/061-development-log-ii.html -[btcbase-1911356]: http://btcbase.org/log/2019-05-06#1911356 -[btcbase-1911437]: http://btcbase.org/log/2019-05-06#1911437 -[btcbase-1916132]: http://btcbase.org/log/2019-05-29#1916132 -[github]: https://github.com/edicl/hunchentoot -[btcbase-1916277]: http://btcbase.org/log/2019-05-30#1916277 -[btcbase]: http://btcbase.org/ -[tmsr-delay]: /posts/y05/090-tmsr-work-ii.html#selection-219.104-223.1 -[btcbase-1914648]: http://btcbase.org/log/2019-05-18#1914648 -[btcbase-1829442]: http://btcbase.org/log/2018-06-25#1829442 -[no-ssl]: http://archive.is/MP2bT#selection-401.1-420.0 diff --git a/posts/y05/093-hunchentoot-i.markdown b/posts/y05/093-hunchentoot-i.markdown new file mode 100644 index 0000000..8d3ca86 --- /dev/null +++ b/posts/y05/093-hunchentoot-i.markdown @@ -0,0 +1,113 @@ +--- +postid: 093 +title: A review of Hunchentoot's code history +date: June 12, 2019 +author: Lucian Mogoșanu +tags: tech, tmsr +--- + +This post is part of a series on [Common Lisp WWWism][cl-www]. Before +continuing, please read [prior discussions][cl-www] on the subject. + +As mentioned in an [older study][development-log-i] (admittedly, a more +superficial one) of Common Lisp web servers, [Hunchentoot][hunchentoot] +is a monster with many tendrils -- in truth, one of the very few +CL-based HTTP servers used in production nowadays. On the surface it +weighs about six or seven thousand lines of code, depending on whether +we count the comments. In depth it exposes a complex architecture, with +support for e.g. cookies and sessions and other usefuls, but most +importantly, its interface offers a ton of flexibility in handling +requests and distributing workloads. + +I've previously found this to be too much for my needs and thus went for +[something simpler][development-log-ii], at least on the +surface. However, following [feedback][btcbase-1911356] and +[further discussion][btcbase-1911437], and in light of the Republican +need for a proper HTTP server, I have decided to review what the CL +ecosystem has on offer, and more precisely to have another good look at +Hunchentoot. + +This sounded easy enough at the beginning, especially that it wasn't the +first time. Only a Hunchentoot genesis would need to start *somewhere*, +and the problem is there are no less than 111 somewheres to start from +if we're to count the so-called "versions" in the CHANGELOG file, and +almost 600 patches, that is, also "versions", although for some unknown +reason those are thought of as something else by the original +authors. Having realized this, I did two things: firstly, I +[asked][btcbase-1916132] for input from Hunchentoot users in the WoT; +and secondly, I put my hazmat suit on and took a walk through the depths +of Hunchentoot history, so as to have it inform my future decisions. + +Below lies (with bullets!) the result of this documentation, in the form +of a summary that groups changes into various categories, +e.g. bugfixing, robustness, API changes etc. Looking at the changelog in +chronological order, we see: + +* Version 0.4.0: First version that comes with SBCL support (among + others). Changes up until then have to do mostly with stability and + small features, e.g. chunked encoding, keepalive. +* Versions 0.4.x: Mostly bug fixing, e.g. in mod_lisp, some SSLism. +* Versions 0.5.x: RAW-POST-DATA behaviour changes, added flexibility. +* Versions 0.6.x: Bugs, robustness. +* Versions 0.7.x: Support compilation without SSL; support Win32. +* Versions 0.8.x: Robustness, bugfixing. +* Versions 0.9.x: More Allegro/SBCL/etc. support; more interface + flexibility. +* Versions 0.{10-14}.x: Debugging support, bugfixing, robustness. +* Versions 0.15.x: CLISP support; added CL-FAD as dependency; bugfixing, + small interface changes. +* Version 1.0.0: Architectural redesign, small fixes, improvements. +* Versions 1.1.x: Architectural changes, bugfixes, shawarma, e.g.: + "safeguard measures against XSS attacks". Why does JavaScript sanity + need to be encoded in the *implementation* of a HTTP server anyway? + +Version 1.2 is where development on GitHub begins and code changes can +be examined. Versions prior to 1.2.0 seem to have been lost. + +* Versions 1.2.{0-9}: Many bugfixes, documentation updates; also SSLism, + support for non-SSL mode, portability, cookie handling, + multithreading. +* Versions 1.2.{10-16}: Functionality to get local address and port; + also, bugfixes, documentation. +* Versions 1.2.{17-24}: Multithreading API changes; also, bugfixes, + portability, documentation; support is added for new MIME type -- why + does the list of MIME types need to be part of the *code* and not a + config parameter?; also, robustness, code sanity. +* Versions 1.2.{25,26}: HTTP header handling; SSLism, code sanity. +* Versions 1.2.{27,28}: Documentation updates, bugfixing, code cleanup, + IPv6 support, other new functionality, robustness. +* Version 1.2.29: Revert IPv6 changes. +* Versions 1.2.{30-38}: Robustness, bugfixing, documentation, support + for "additional HTTP status codes" (RFC 6585), multithreading + optimizations, support for ports allocated by the system. Phf + [is using][btcbase-1916277] version 1.2.35 for [btcbase][btcbase], + which makes this the likeliest starting point for a genesis. + +Beyond version 1.2.38, Hunchentoot seems to have gone vaguely "agile", +in the "move fast and break things" fashion. This includes SSLism +changes, reintroduced support for IPv6 (which seems to bump up the +required usocket version) and other potential breakages. Thus, I'm not +going to look further in that direction. + +As a side note, [my hunch][tmsr-delay] was unfortunately not at all +unfounded: although I have given myself [ample time][btcbase-1914648] to +look at this, it still hasn't been enough, and here I am, about halfway +through the work. As a side note to the side note: although I will +genesize nothing less than a working item, I also expect the item in +question to be [not at all pretty][btcbase-1829442], and full of warts +etc., although in principle -- *in principle* -- it should be fairly +easy to cut e.g. [SSLism][no-ssl] out. + +[cl-www]: /posts/y05/090-tmsr-work-ii.html#selection-108.0-108.17 +[development-log-i]: /posts/y03/05c-development-log-i.html#selection-187.0-192.0 +[hunchentoot]: https://edicl.github.io/hunchentoot/ +[development-log-ii]: /posts/y03/061-development-log-ii.html +[btcbase-1911356]: http://btcbase.org/log/2019-05-06#1911356 +[btcbase-1911437]: http://btcbase.org/log/2019-05-06#1911437 +[btcbase-1916132]: http://btcbase.org/log/2019-05-29#1916132 +[btcbase-1916277]: http://btcbase.org/log/2019-05-30#1916277 +[btcbase]: http://btcbase.org/ +[tmsr-delay]: /posts/y05/090-tmsr-work-ii.html#selection-219.104-223.1 +[btcbase-1914648]: http://btcbase.org/log/2019-05-18#1914648 +[btcbase-1829442]: http://btcbase.org/log/2018-06-25#1829442 +[no-ssl]: http://archive.is/MP2bT#selection-401.1-420.0