cpp-httplib : une bibliothèque HTTP/HTTPS à fichier unique avec des limites explicites

Portée et limites explicites

cpp-httplib est une bibliothèque C++11 distribuée sous forme d'un seul fichier d'en-tête. Le README indique qu'il suffit d'inclure httplib.h. Elle fournit à la fois des implémentations de serveur et de client, avec la prise en charge SSL/TLS via OpenSSL, MbedTLS ou wolfSSL. La bibliothèque utilise des E/S de socket bloquantes et n'implémente que HTTP/1.1 ; HTTP/2 et HTTP/3 ne sont pas disponibles. Les plateformes 32 bits ne sont pas prises en charge ; le mainteneur déclare qu'aucun examen de sécurité n'a été effectué pour les environnements 32 bits et que les rapports de sécurité affectant uniquement ces plateformes seront fermés sans action. Les métadonnées du dépôt montrent 16 719 étoiles et 2 723 forks, mais le README lui-même ne prétend rien sur la préparation à la production.

Configuration et premiers exemples

La bibliothèque est incluse en ajoutant httplib.h à un projet. Le code serveur crée un httplib::Server ou httplib::SSLServer, enregistre des gestionnaires avec des méthodes comme Get, Post, et écoute sur une adresse et un port. Le code client utilise httplib::Client ou httplib::SSLClient, et appelle des méthodes comme Get, Post, Put, Patch, Delete, Options. Le README montre un serveur minimal qui renvoie 'Hello World!' et un client qui imprime le corps de la réponse. Pour HTTPS, l'exemple définit CPPHTTPLIB_OPENSSL_SUPPORT avant d'inclure l'en-tête. Le README ne spécifie pas de système de build ni de gestionnaire de paquets ; il pointe simplement vers le fichier unique.

Routage serveur, fichiers statiques et journalisation

Les gestionnaires serveur peuvent faire correspondre des chemins de manière littérale, par expression régulière, ou avec des paramètres de style :id qui remplissent req.path_params. Les gestionnaires peuvent lire les en-têtes, les paramètres de requête et le contenu du corps. Le serveur peut servir des fichiers statiques depuis un ou plusieurs points de montage, avec des mappages de types MIME définis par l'utilisateur et des mappages intégrés pour les extensions courantes. Le README avertit que les méthodes de fichiers statiques ne sont pas thread-safe. Des journaux d'accès et d'erreurs peuvent être attachés via set_logger et set_error_logger. Il existe également des gestionnaires de pré-routage, post-routage, pré-requête, d'erreur et d'exception, avec un ordre d'exécution documenté. Le gestionnaire de pré-requête s'exécute après la correspondance de route mais avant la lecture du corps de la requête, ce qui permet de rejeter une requête sans mettre en mémoire tampon un corps volumineux.

Fonctionnalités des requêtes client

Le client prend en charge GET, POST, PUT, PATCH, DELETE et OPTIONS. Il peut envoyer des données de formulaire multipart, téléverser des fichiers depuis le disque sans les charger en mémoire avec make_file_provider, et poster des corps de fichiers bruts avec make_file_body. Les méthodes d'authentification incluent basic, digest et bearer token ; digest nécessite OpenSSL. La prise en charge des proxys inclut l'authentification basic, digest et bearer token, ainsi qu'une liste no-proxy qui accepte les wildcards, les suffixes de nom d'hôte, les littéraux IP et les blocs CIDR. Le client peut suivre les redirections, définir des délais, limiter la taille de la charge utile et utiliser une interface réseau spécifique, bien que la fonction d'interface ne soit pas disponible sous Windows. Une note de performance dans le README avertit que sous Windows, l'utilisation de 'localhost' peut entraîner des retards dus au DNS, et suggère d'utiliser '127.0.0.1' à la place.

Backends SSL/TLS et gestion des certificats

La prise en charge SSL est sélectionnée avec une définition de préprocesseur : CPPHTTPLIB_OPENSSL_SUPPORT pour OpenSSL 3.0 ou ultérieur, CPPHTTPLIB_MBEDTLS_SUPPORT pour Mbed TLS 2.x/3.x/4.x, ou CPPHTTPLIB_WOLFSSL_SUPPORT pour wolfSSL 5.x compilé avec --enable-opensslall. La bibliothèque expose ssl_error() et ssl_backend_error() pour le diagnostic. Une vérification personnalisée des certificats peut être effectuée avec set_server_certificate_verifier, et les certificats pairs peuvent être inspectés côté serveur via req.peer_cert(). Sur macOS et Windows, la bibliothèque s'intègre automatiquement au magasin de certificats du système d'exploitation, avec des options de compilation pour désactiver cela. Le README note un problème SIGPIPE avec SSL qui peut nécessiter un gestionnaire de signal. BoringSSL est pris en charge au mieux, avec quelques différences connues.

Streaming, transfert en morceaux, SSE et WebSocket

Le serveur et le client prennent en charge les récepteurs et fournisseurs de contenu, ce qui permet de diffuser de grands corps sans les conserver entièrement en mémoire. Le transfert en morceaux est disponible des deux côtés, y compris la possibilité d'envoyer des en-têtes de fin. Une API Stream distincte dans l'espace de noms httplib::stream traite les réponses par morceaux, et toutes les méthodes HTTP sont couvertes. Les événements serveur (SSE) sont implémentés via httplib::sse::SSEClient côté client et un exemple serveur. Le support WebSocket existe pour le serveur et le client, avec un modèle thread par connexion destiné aux charges de travail petites à moyennes ; les extensions comme permessage-deflate ne sont pas implémentées. Le README recommande de configurer un pool de threads dynamique si de nombreuses connexions WebSocket simultanées sont attendues.

Limites de ressources, compression et extras de déploiement

La taille maximale de charge utile par défaut est de 100 Mo pour le serveur et le client, ajustable avec set_payload_max_length ou la définition CPPHTTPLIB_PAYLOAD_MAX_LENGTH au moment de la compilation. La compression est prise en charge via zlib, brotli et zstd, avec des définitions pour chacune. L'en-tête Accept-Encoding par défaut inclut tous les types de compression pris en charge. Le serveur utilise un pool de threads qui évolue dynamiquement ; le nombre de base par défaut est le plus grand de 8 ou hardware_concurrency moins un, et peut évoluer jusqu'à quatre fois cette valeur. Les sockets de domaine Unix sont disponibles sous Linux et macOS. Un script split.py peut séparer l'en-tête en fichiers .h et .cc, et un Dockerfile sert des fichiers statiques depuis /html. Le projet est sous licence MIT, qui accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies, mais fournit le logiciel sans garantie.

Conclusion éditoriale

cpp-httplib rassemble une grande partie des fonctionnalités serveur et client HTTP dans un seul fichier d'en-tête, et il est tout aussi explicite sur ce qu'il exclut : E/S bloquantes, HTTP/1.1 uniquement, et pas de support 32 bits. Cette clarté rend la bibliothèque facile à évaluer par rapport aux exigences d'un projet. Pour cpp-httplib, le premier contrôle doit porter sur la commande d’installation et la configuration indiquées dans le README, puis sur la sortie attendue dans votre environnement.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes