H2o: Crash lors de la réinitialisation de la connexion lors du traitement des demandes de manière asynchrone

Je soupçonne que mon problème est que j'utilise h2o_send_inline et que je devrais utiliser un générateur sur lequel stop() est appelé si la connexion disparaît, et que je devrais enregistrer le générateur avant de rendre le contrôle à la boucle d'événement h2o. N'hésitez pas à me dire si je pense dans le bon sens !

Je devrais utiliser un générateur sur lequel stop() est appelé si la connexion disparaît, et que je devrais enregistrer le générateur avant de rendre le contrôle à la boucle d'événement h2o.

Oui! Oui! Oui! Merci d'avoir cherché vous-même la bonne réponse !

Je pense que cela a réglé le problème ! C'est la disponibilité de doh.powerdns.org.
Existe-t-il une documentation de la bibliothèque h2o où je pourrais contribuer à une description des restrictions d'utilisation des fonctions _inline lorsque je travaille de manière asynchrone ?

Fantastique! Bon à savoir que dnsdist-doh fonctionne bien !

Malheureusement, nous n'avons pas de bon point pour la documentation, même si je pense que ce serait une bonne idée d'ajouter l'avertissement au commentaire de doc pour h2o_send_inline dans include/h2o.h.

Il peut également être utile de mentionner que h2o_send_inline() crée une copie de son entrée en tant que considération de performance. Cela signifie également que la fonction ne s'approprie pas le paramètre, ce dernier peut donc être désalloué immédiatement après son retour à l'appelant.

Je suis un peu confus par la documentation ajoutée en #1896 car cette dernière semble contredire ce qui a été dit en #142. J'utilise la boucle d'événements libh2o pour gérer les connexions à la base de données, mon workflow ressemble donc à ceci :

1. Une requête HTTP est reçue par le serveur.
2. Le rappel h2o_handler_t::on_req ne fait rien d'autre que démarrer une requête de base de données asynchrone (en utilisant h2o_socket_read_start() et h2o_socket_notify_write() si nécessaire) et retourner 0 - en particulier, il n'appelle pas h2o_start_response() ou h2o_send_inline() (ou quelque chose de similaire).
3. Le contrôle revient à la boucle d'événement libh2o .
4. Le résultat de la requête de base de données arrive et est géré par un rappel. Ce dernier appelle soit h2o_send_inline() soit h2o_start_response() suivi d'une série d'invocations h2o_send() .

D'après les commentaires du n° 142, c'est correct car au point 3, il n'y a pas assez d'informations pour générer les en-têtes de réponse HTTP (par exemple, la taille du corps de la réponse dépend du résultat de la requête de base de données, qui n'a pas encore été reçu), il est donc trop tôt pour enregistrer le générateur.

J'ai parcouru l' implémentation du proxy inverse , et il semble faire une chose plus ou moins similaire - pour autant que je sache, la première fois qu'il utilise h2o_start_response() est dans la fonction on_head() , qui, si j'ai bien compris, est appelé après que le serveur d'origine ait renvoyé la première partie de la réponse au proxy (ce qui correspond au point 4 de mon workflow). Par contre, d'après ma lecture de #1896 j'ai besoin de définir le rappel h2o_generator_t::stop et d'appeler h2o_start_response() au point 2 avant de retourner 0, afin d'éviter un accès potentiel à la mémoire désallouée . Alors, quelle est la bonne approche, ou est-ce que j'ai raté quelque chose ?

@volyrique Merci d'avoir soulevé la question. Je me rends compte maintenant que j'ai causé de la confusion.

Permettez-moi d'expliquer cela d'une manière différente.

h2o_req_t est supprimé lorsque le client ferme la connexion sous-jacente ou supprime brutalement un flux HTTP/2. Les applications asynchrones doivent détecter cela et éviter d'utiliser h2o_req_t par la suite.

Il y a deux façons d'y parvenir.

La première consiste à enregistrer le générateur sur h2o_req_t pour recevoir le rappel stop du générateur appelé. L'inconvénient, comme vous le soulignez correctement, est que le générateur est enregistré en appelant h2o_start_response : une fonction qui ne peut être appelée qu'une fois que le code d'état et les en-têtes de réponse sont prêts.

L'autre méthode consiste à allouer une mémoire avec un rappel dispose partir du pool de mémoire de la requête ¹ . Le gestionnaire de proxy utilise cette technique (voir lib/core/proxy.c ligne 553 de la version 2.2.5 ) ; c'est on_generator_dispose est appelé lorsque le h2o_req_t est défaussé.

@ahupowerdns J'espère que ce commentaire clarifie mieux le fonctionnement de H2O. J'espère que vos modifications ne sont pas basées sur l'hypothèse erronée que le rappel stop sera invoqué avant même que vous n'appeliez h2o_start_response pour lier le générateur à la réponse. Et enfin, merci d'avoir soumis le #1896 ; Je vais apporter des modifications au PR pour refléter ce que j'ai écrit ici et le fusionner.

[1] La fonction utilisée pour allouer de la mémoire avec un rappel dispose est appelée h2o_mem_alloc_shared , car c'est l'une des capacités d'une allocation de mémoire "partagée" (c'est-à-dire comptée par référence).

dnsdist-doh utilise maintenant h2o_mem_alloc_shared qui est 1) plus facile et 2) en fait meilleur car il nous permet de stocker exactement quelle demande a été interrompue. En utilisant la méthode 'stop', vous obtenez un signal que 'req' doit s'arrêter, mais h2o s'avère réutiliser rapidement ce même req ptr dans la pratique, vous devez donc faire très attention à annuler le bon travail en suspens. En utilisant h2o_mem_alloc_shared, vous pouvez ajouter un pointeur vers votre propre état. Merci!