From: Lucian Mogosanu Date: Tue, 20 Aug 2019 09:10:06 +0000 (+0300) Subject: drafts: Add hunchentoot-vi intro X-Git-Url: https://git.mogosanu.ro/?a=commitdiff_plain;h=8c2a352ce9690826b95c44a99f14332331fa8964;p=thetarpit.git drafts: Add hunchentoot-vi intro --- diff --git a/drafts/000-hunchentoot-vi.markdown b/drafts/000-hunchentoot-vi.markdown new file mode 100644 index 0000000..c5da5f8 --- /dev/null +++ b/drafts/000-hunchentoot-vi.markdown @@ -0,0 +1,91 @@ +--- +postid: 000 +title: Hunchentoot: requests and replies +date: August 23, 2019 +author: Lucian Mogoșanu +tags: tech, tmsr +--- + +This post is part of a series on [Common Lisp WWWism][cl-www], more +specifically dissecting the Common Lisp web server known as +Hunchentoot. Other posts in the series include: + +* a walk through the project's [history][ht-i]; +* a set of [architectural notes][ht-ii] and [follow-up][ht-iii] on the + same; +* a review of [acceptors][ht-iv]; and +* a review of [taskmasters][ht-v]. + +This post will discuss the objects known as "requests" and "replies", +as they are part of the very same fundamental mechanism. + +The reader has probably noticed that [little][chunking] to nothing has +been discussed about the core of this whole orchestra, the core being +the *HTTP* piece -- yes, we're what looks like more than halfway +through this series and most of what we've discussed comprises +[TCPisms][tcp] and [CL-on-PC][alf-cl-on-pc]. So let's begin our +incursion into the subject with a [likbez][likbez]: + +The idea behind HTTP is simple: let there be a network of nodes N; let +the nodes be divided into client nodes C and server nodes S[^1]; let +every node s in S be associated with a set of resources Rs. In this +framework, HTTP specifies a means for a client c in C to access a +resource r in Rs, knowing that s in S is a server. Furthermore, it +allows one c to interact with an r owned by s in other ways, such as +by "posting" data to that r. Additionally, newer specifications of the +protocol have introduced other so-called "methods" of interaction; I +will deliberately omit them, both for the sake of brevity and because +all or most of the "additional" stuff is to be burned down and left +out of any such future "HTTP" protocol[^2]. + +So let's say that a c in C wants to interact with a s in S as per +above. The premise being that c and s communicate using HTTP, then c +will send s a message called a request, which contains the resource to +be accessed, the method and other such information, as specified in +the [RFC][rfc-1945-5]. Upon receiving this request message, s will +respond to c with a message called a response, which contains a status +code, the message size, the data and so on, again, as per the +[RFC][rfc-1945-6]. This is then (as viewed from the airplane) the +whole mechanism that our Hunchentoot needs to implement in order to be +able to communicate with curls, web clients, proxies and so on: +receiving and processing requests; and baking and sending +replies. Note that Hunchentoot merely provides *the mechanism* for +this; the actual policy (i.e. whether a resource is to be associated +with a file on the disk, or a set of database entries or whatever) is +implemented by the user. + +[^1]: In practice some c in C can also be a s in S and vice-versa, why + not? In a sane world C and S would be the same set, and thus our + client-server-herpderp model would become that of a peer-to-peer + network, that is, one in which all nodes would both host resources + and ask for them. Again, I ask: why not? And if not, then pray + tell, why does the [Incan][inca] star topology appeal so much to + you? + +[^2]: Witness, just as an example, the difference between RFCs + [1945][rfc-1945] and [2616][rfc-2616]: the former specifies + precisely three methods -- of which the second is, for purely + practical reasons, a subset of the first -- while the + latter... well! + + By the way, do you think this is all? Nope: current specifications + split HTTP into no less than [seven parts][http-rfcs], which makes + this a tome of its own. And as if this wasn't enough, as of 2019 + RFC 7230 has been obsoleted by [8615][rfc-8615], and if this keeps + up at the current pace God help us, by 2029 we'll probably get to + RFCs numbered in the hundred thousands. + + In other words, fuck these sons of bitches and all their cancerous + "improvements". + +[chunking]: /posts/y06/098-hunchentoot-iv.html#fn2 +[tcp]: /posts/y05/096-hunchentoot-ii.html#fn1 +[alf-cl-on-pc]: http://trilema.com/2019/trilema-goes-dark/#comment-130686 +[likbez]: http://logs.nosuchlabs.com/log-search?q=likbez&chan=trilema +[inca]: http://trilema.com/republican-thesaurus/?b=(cca%202016&e=femstate.#select +[rfc-1945]: https://tools.ietf.org/html/rfc1945#section-5.1.1 +[rfc-2616]: https://tools.ietf.org/html/rfc2616#section-5.1.1 +[http-rfcs]: https://www.w3.org/Protocols/ +[rfc-8615]: https://tools.ietf.org/html/rfc8615 +[rfc-1945-5]: https://tools.ietf.org/html/rfc1945#section-5 +[rfc-1945-6]: https://tools.ietf.org/html/rfc1945#section-6