Vidocq Documentation

Chappe est un serveur HTTP haute performance écrit en Java 25 pur, sans aucune dépendance hors JDK. Il implémente HTTP/1.1 (RFC 9110/9112), HTTP/2 (RFC 9113) et — à terme — HTTP/3 (RFC 9114). Il sert de couche transport à l’écosystème Vidocq : Foy (Servlet) et Cassini (REST) se montent par-dessus.

Origine du nom

Claude Chappe (1763-1805), ingénieur français, inventeur du télégraphe optique mis en service en 1794. Son réseau de 556 stations à sémaphores articulés couvrait la France entière et transmettait un message de Paris à Toulon en moins de quinze minutes — la première vraie infrastructure de communication longue distance, plusieurs décennies avant Morse.

Voir Claude Chappe sur Wikipédia.

La métaphore tient sur deux points :

  • Chappe (le serveur) est la couche transport — il déplace des octets, sans intelligence applicative, exactement comme une station optique relayait des codes sans les interpréter.

  • L’administration française du télégraphe Chappe a été reprise par Alphonse Foy au XIXe siècle. Dans Vidocq, Foy (Servlet 6.1) hérite de la même façon du transport Chappe.

En un coup d’œil

Spec implémentée

HTTP/1.1 (RFC 9110, RFC 9112), HTTP/2 (RFC 9113), HTTP/3 (RFC 9114, planifié)

Repo

https://codeberg.org/Vidocq/chappe

Java

25 (LTS)

Modules JPMS

io.vidocq.chappe.api, io.vidocq.chappe.http, io.vidocq.chappe.core, io.vidocq.chappe.cli

Dépendances runtime

zéro (JDK uniquement)

Conformité

45 tests RFC dans chappe-conformance ; 113 tests d’intégration dans chappe-tests

TCK

non applicable (pas de TCK officiel HTTP)

Positionnement dans l’écosystème

Chappe est au cœur du transport : tout module Vidocq qui parle HTTP transite par lui.

Diagram

Chappe peut aussi fonctionner sans extension : c’est ce que fait sa CLI chappe serve pour servir un site statique en production.

Caractéristiques identitaires

  • Java 25 strict — ScopedValue (JEP 506), pattern matching exhaustif, sealed interfaces, records.

  • Virtual Threads — un thread virtuel par connexion, pas de pool plateforme, pas de Selector applicatif.

  • JPMS strict — chaque module a son module-info.java, exports minimaux, pas de classpath.

  • Zéro dépendance — pas de logger transitif, pas de bibliothèque utilitaire externe. Tests JUnit uniquement.

  • Génération statique — chappe-static-index-maven-plugin produit l’index O(1) et les sidecars .gz au build.

  • Zero-copy I/O — FileChannel.transferTo() pour les fichiers statiques et les sidecars pré-compressés.

Performance

Lecture rapide (TL;DR, tableau canonique, profil JFR, comparatif natif vs JVM) : page Performance. Le journal complet de tous les runs (closed-loop in-process et open-loop wrk2), la méthodologie détaillée et l’historique des optimisations sont consignés dans lien:https://codeberg.org/Vidocq/chappe/blob/main/BENCHMARKS.md[BENCHMARKS.md].

Ressources rapides

  • Démarrage rapide — premier serveur en moins de 30 lignes.

  • Cas d’usage — TLS, HTTP/2, virtual hosts, fichiers statiques, compression, CLI.

  • Concepts — connexion, frame, multiplexage, scoped values.

  • Fonctionnement interne — pipelines HTTP/1.1, HTTP/2, HTTP/3 ; modèle threading.

  • Référence — coordonnées Maven, packages JPMS, API publique, plugin Maven.

  • Migration — depuis Netty, Undertow, Jetty, JDK HttpServer.