--- /dev/null
+---
+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
projects / thetarpit.git / commitdiff