Construire un serveur HTTPS sans framework
Création, depuis zéro, d’un serveur Web HTTPS avec routage, gestion des signaux, erreurs, fichiers statiques et types MIME.
- Contexte
- Projet universitaire
- Rôle
- Conception et développement système en C
- Statut
- Terminé
Trace technique · 04
- C
- HTTP
- HTTPS
- TLS
- Sockets
- MIME
- Linux
- Requête HTTP → routage → réponse
- HTTPS, fichiers statiques et types MIME
- Erreurs et arrêt du processus gérés explicitement
Reprendre la main sur les fondations du Web.
Problématique
L’objectif n’était pas d’assembler un serveur existant, mais de comprendre et de construire les mécanismes qui relient une requête, une réponse et le cycle de vie d’un processus. Il fallait répondre correctement, rester explicite sur les erreurs et préserver le service lors de son arrêt.
Mission
Développer un serveur HTTPS sans framework ni bibliothèque Web, capable de router des demandes, servir des fichiers, reconnaître les types MIME et gérer les signaux ainsi que les erreurs de manière contrôlée.
Faire tenir le protocole dans un programme lisible.
- 01
Lire et qualifier la requête
Recevoir la connexion, interpréter les éléments utiles de la requête HTTP et orienter chaque chemin vers une réponse attendue plutôt que vers un comportement implicite.
- 02
Servir les bons contenus
Associer les ressources statiques à leurs types MIME afin que le navigateur puisse comprendre le contenu reçu et que les réponses restent cohérentes.
- 03
Sécuriser le transport
Intégrer la couche HTTPS au cycle de réponse pour traiter les échanges sécurisés sans déléguer la logique Web à un framework.
- 04
Prévoir les sorties de route
Traiter les erreurs, les signaux et l’arrêt du processus pour que le serveur conserve un comportement maîtrisé lorsque la demande ou l’environnement ne sont pas idéaux.
Un serveur simple, mais responsable de chaque étape.
Ce projet a rendu concrètes des abstractions habituellement cachées par les frameworks : une requête n’est pas une simple fonction, et une réponse dépend du protocole, du système, du cycle de vie du processus et de choix précis de gestion d’erreur. Cette compréhension influence ensuite mes choix FullStack : je sais mieux ce qu’un outil simplifie et ce qu’il ne faut pas lui demander de masquer.
- Un serveur Web HTTPS développé à partir de primitives système et réseau.
- Un routage et un service de fichiers statiques explicitement contrôlés.
- Une prise en charge des types MIME et des cas d’erreur courants.
- Une gestion des signaux qui replace le cycle de vie du processus au cœur de la conception.