Pretty neat! I see that you’re using Hunchentoot — are you concerned that it interns HTTP header names in the KEYWORD package? It means that a malicious client can use up all your RAM by submitting requests with random header names.

Thank you for your comment. This is a great point! I had not considered this earlier but after looking at https://github.com/edicl/hunchentoot/blob/master/request.lis... it is clear that this could potentially lead to denial of service.

I have now updated the Nginx configuration to block arbitrary headers coming from the remote client and explicitly pass only a limited set of headers to Hunchentoot. So now I have something like this in the Nginx reverse proxy configuration:

  proxy_pass_request_headers off;
  proxy_set_header Accept $http_accept;
  proxy_set_header Content-Length $http_content_length;
  proxy_set_header Content-Type $http_content_type;
  proxy_set_header If-Modified-Since $http_if_modified_since;
  proxy_set_header Referer $http_referer;
  proxy_set_header User-Agent $http_user_agent;
  proxy_set_header X-Forwarded-For $remote_addr;

I will push this configuration to the GitHub repository too sometime this weekend.

Here's an update. The Nginx reverse proxy configuration update to work around the memory leakage issue in Hunchentoot has now been pushed to the GitHub repository of MathB.in too.

Commit: https://github.com/susam/mathb/commit/0dcedc0

Nginx configuration: https://github.com/susam/mathb/blob/main/etc/nginx/https.mat...

This is a pretty subtle security "gotcha" for any program that wants to be clever and intern user-provided inputs as keywords. Good to know!

A simple fix that would be to intern all valid header names into the keyword package on startup, and then when processing a request, use FIND-SYMBOL against the keyword package rather than INTERN. If that fails, just drop that header.

I'd be happy to see a discussion on the issue: https://github.com/edicl/hunchentoot/issues/24

Nice to know about this, and congratulations for its 10th anniversary.

Given that it's not that old, and it's still actively used I wonder why people never include it in the list of recent Common Lisp code bases, for new users to take a look.

It's always the same recommendations.

Thank you! Until a few years ago, this project ran on PHP. It was then later rewritten in Common Lisp. I published the Common Lisp source code for this website only about a week ago. That's why I thought of making this "Show HN" post today.

Until now, the source code published on GitHub has usually been a few versions behind the live website running at https://mathb.in/ but I am hoping that in future, I will keep the source code on GitHub as recent and as updated as possible.

What was the motivation and how was the process of the rewrite?

There were two main motivations: simplifying the code and the features, and writing the software in a programming language that I enjoy programming with.

The process of the rewrite was roughly like this: simplifying HTML, CSS, and JavaScript code first, then switching from MathJax v2 to MathJax v3, then making corresponding changes in the JavaScript code, then replacing the custom Markdown + LaTeX demultiplexing logic with TeXMe that is specifically designed to solve this problem, and finally rewriting the server-side functionality in Common Lisp. The last activity had roughly six phases of development: writing some of the utility functions I would need later (e.g., parsing posts, storing/retrieving posts, etc.), writing tests, presenting the home page, processing the post submission, presenting post pages, and performing post validations.

I will definitely use this. I've been looking for something like this to quickly share my ideas with other students.

The demo really does look nice; I'm bookmarking this right now.

I will use this! I wish I had known about it sooner!