11. Hosting, WebApplication et Kestrel

WebApplication compose configuration, logging, injection de dépendances, middleware et endpoints. Le generic host possède le cycle de vie ; Kestrel possède le transport réseau.

Ce que le builder assemble

CreateBuilder charge les sources de configuration et les services. Build fige ce graphe en application. StartAsync démarre les hosted services et le serveur ; StopAsync lance l’arrêt gracieux.

Le programme lie Kestrel à un port loopback éphémère, appelle réellement /health et observe les callbacks :

started callback observed: True
GET /health: 200 {"status":"ready"}
graceful stop callbacks observed: stopping=True, stopped=True

Cela prouve la composition du cours, pas la readiness de production. Il faut encore déclarer limites, timeouts, confiance accordée aux forwarded headers, terminaison TLS et budget d’arrêt.

Gracieux ne veut pas dire infini

ApplicationStopping demande d’arrêter l’admission. Le travail en vol doit finir dans le budget ou laisser une preuve durable de récupération. En conteneur, le timeout du host doit rester inférieur à la période de grâce de l’orchestrateur.

Exécuter la preuve

dotnet run --project code/csharp-advanced/Advanced -c Release -- l11

La sortie vérifiée est expected/l11.txt.

Exercices

1. Ajouter un endpoint lent qui observe RequestAborted, puis déclencher l’arrêt.
2. Fixer une petite limite de body Kestrel et tester juste en dessous et au-dessus.
3. Tester les forwarded headers avec un proxy autorisé et une requête directe qui les usurpe.

Solutions

1. Prouver que la requête a démarré, appeler StopAsync avec un token borné et enregistrer la cancellation observée.
2. Configurer avant Build, vérifier le statut et prouver que l’endpoint rejeté n’a pas été appelé.
3. Déclarer explicitement les proxies/réseaux connus ; une requête directe ne doit pas choisir son identité client.