My own HTML server from scratch

I embarked on an exciting project to program an HTML server on a Raspberry Pi using C++. My journey began with the development of a simple TCP/IP server, where I created a custom packet handling system to transfer files from my PC to the Raspberry Pi server. This foundational work provided me with a solid understanding of network communication and file transfer protocols.

Building on this experience, I developed an HTTP server to allow access to the website via standard web browsers. This required handling HTTP requests and responses to ensure the smooth delivery of web pages and resources. At this stage, I also began learning HTML and CSS to design and layout the website. I configured my router to reroute incoming HTTP traffic to the Raspberry Pi server, making the website accessible globally. Additionally, I implemented a dynamic IP updater using a free dynamic DNS service from no-ip, ensuring continuous access even when the IP address changed.

To enhance security, I upgraded the server to support SSL, transforming it into an HTTPS website. This step involved implementing encryption protocols to secure data transmission between the server and clients, ensuring a safe and reliable browsing experience. I purchased an SSL certificate from the same provider that offered the dynamic DNS service.

Next, I added a dark theme to the website, complete with a toggle button in the top right corner of the header for easy access. I used local storage to remember the user's theme preference, ensuring the website always loads in the preferred theme without relying on cookies, keeping the site lightweight.

Following my father's suggestion, I introduced a feature to change the website's language. I added a language selector dropdown menu in the header, allowing users to choose their preferred language. I then incorporated a function in the main JavaScript file to change the website's language based on the user's selection, and utilized local storage to remember the preference for future visits.

Following all this work on the front end, I decided to enhance the server's back end by implementing a dynamic html page builder. This feature allowes me to merge multiple html files into a single html file, which is then sent to the client. I used it to add the header and the footer to all the pages on the website, making it easier to maintain and update the website in the future.

Adding the JS file build feature to the server has brought a lot of problems which I knew I had to solve. The major problem was that I had to make my own JSON parser, because I'm using a open source one. It'sn't bad, but it isn't fit for my stile of coding. I need it for a lot of configurations and I wanted to use it for the JS file build feature. Right now the JS file build is a fixed map of the files that are going to be merged. I'm going to change that in the future, but for now it's enough.

I've been working on the server for a while now and I'm really happy with the results. But I wanted to expand the servers capabilities. I wanted to add a multi-domain support. This means that I can host multiple websites on the same server. To implement this I had to change a lot of the server's code.

I wrote my own JSON parser to parse the configuration file for the server. This configuration file contains all the information about the domains that are hosted on the server: where the files are located, what the domain is, where the SSL certificate is located, etc.

I also had to change the way the server handles the incoming requests. Now the server checks the host header of the request and serves the files from the correct domain with the correct SSL certificate.

I've also bought a domain for the website. I've been thinking about it for a while now and I think it's time to make the website more professional. I've also bought a new SSL certificate for the domain.

After adding the multi-domain support to the server, I wanted to redo my logger. I've done it quite simply at the beginning, just writing to an CSV file. But I wanted to integrate an SQLite database and the logs seems like a good place to start. I've written a SQLite interface to have a simple way to interact with the database. It's an singleton class that I can use to insert logs into the database from anywhere in the server. One of the next steps will be to add an API to the server to get the logs from the database.

Well, I've added a 'log' page to see the different logs (connexion log, error log, api log, etc). I use an api which returns an array of JSONs which represent each one log. I've also added a way to filter by IP, date and domain. This way I can easier track traffic and errors on the server. I will also add a way to delete logs in the future to keep the database clean.

Since the beginning, I wanted to add a simple game to be played on my websites. I wanted a game which doesn't require complicated user input and which is easy to implement. I've decided to implement the game Reversi. I've started by adding new API endpoints to the server to get the board and to play a move. Only one game can be played at a time across all the domains, but for the moment it's enough.

I have updated the entire stack of my webserver. Previously, a single program handled the SSL certificate, the HTML server, the API, and the Modbus RTU service. Now, I have transitioned to using Docker, which has significantly improved the modularity and maintainability of the system. I use Traefik for automatic SSL certificate management, a Docker image for the HTML webserver, another image for the API, and a third image for the Modbus RTU service. This change was driven by the need for better scalability, easier updates, and improved isolation of services, which Docker provides.

The previous monolithic approach made it difficult to manage and update individual components without affecting the entire system. By breaking down the services into separate Docker containers, I can now update or modify each service independently, reducing downtime and improving overall system reliability. Additionally, Docker's containerization ensures that each service runs in its own isolated environment, minimizing conflicts and making the system more secure.

I've added dynamic generation of static webpages for each supported language. When a webpage is requested, the server checks if the page for this language has already been created. If not, it will create it using the template page. If the page is older than a certain number of hours, it will also recreate it.

This way, my JavaScript file doesn't need to include all the translations for each language. Only the bare minimum is sent to the browser.

This approach also speeds up subsequent requests because the static part of the page is already generated. Additionally, pages that aren't accessed in a specific language won't be created, reducing disk space usage.