Lors de l’envoi d’une requête HTTP, il est possible d’envoyer les données bloc par bloc (chunked). Ceci permet de s’abstraire de la taille totale des données échangées et de transmettre le contenu de manière progressive. Pour ce faire, il faut utiliser l’en-tête de requête HTTP « Transfer-Encoding: chunked ».
Ce mode d’envoi est utile notamment :
Ainsi, grâce aux requêtes HTTP chunked, les applications sont plus réactives. Elles rencontrent également moins d’erreurs lorsque le contenu transmis est moins volumineux.
Pour comprendre en détail comment fonctionne le chunk, vous pouvez consulter cette page.
J’ai développé une API (dans Azure API Management) qui reçoit une requête HTTP et transmet son contenu à une logic app. Lors de la phase de test de mon développement, j’utilise Postman pour envoyer la requête HTTP à l’API. De mon côté tout fonctionne, je déploies donc mon développement.
Je remarque très rapidement que mon flux ne fonctionne pas lorsqu’un système tiers le consomme. En analysant les exécutions, je constate qu’APIM reçoit bien la requête et que son contenu apparaît dans App Insight. En revanche, dans la logic app je récupère uniquement les en-tête, mais pas le contenu :
J’aperçois alors qu’il y a un en-tête supplémentaire sur l’exécution générée par le système tiers par rapport à Postman : « Transfer-Encoding »: « chunked ». On observe également que la Logic App ne reçoit que l’en-tête, sans le corps de la requête. De ce fait, la Logic App tombe en erreur sur sa 2ème activité. Elle ne trouve pas l’information voulue dans le corps de la requête absent.
Pour solutionner ce problème de requêtes HTTP « chunked », il faut qu’APIM attende d’avoir reçu tous les blocs de la requête émettrice avant d’envoyer les données à la Logic App. Pour ce faire, il faut rajouter dans la policy « inbound » avant l’appel de la Logic App, le code :
<set-body template="none">@{
return context.Request.Body.As<string>(preserveContent: true);
}</set-body>
Ainsi, le système rassemble l’intégralité du corps de la requête entrante avant de l’envoyer à la Logic App.
De cette manière, on obtient désormais le corps de la requête. De plus, nous n’avons plus l’en-tête « Transfer-Encoding »: « chunked » au niveau de la Logic App :
Nous avons désormais trouvé une solution au problème rencontré. Une API exposée via Azure API Management recevait une requête au format « chunked ». Elle la transmettait ensuite directement à la Logic App. Et ce fonctionnement posait problème. Ce cas étant résolu, nous pouvons maintenant prendre du recul. Il faut comprendre comment Azure gère le transfert « chunked » de manière plus générale. Pour cela, intéressons-nous aux ressources Azure les plus utilisées : APIM, Logic Apps et Azure Functions.
Pour commencer, reprenons, comme sur le cas de notre problème, une API dans APIM qui n’appelle cette fois pas de Logic App mais qui affiche juste la requête qu’elle reçoit.
Test n°1 : on envoie une requête HTTP basique sans « preserve-content » :
Premièrement, on utilise pas le mode HTTP « chunk ». Deuxièmement, on ne rajoute pas la policy APIM de « preserve-content » comme vu précédemment. Troisièmement, on envoie un fichier volumineux pour voir si on récupère bien l’intégralité du contenu.
L’APIM reçoit bien le contenu en intégralité. Nous n’avons pas besoin de la policy « preserve-content »
Test n°2 : on envoie une requête HTTP « chunked » sans « preserve-content » :
Premièrement, on utilise le mode HTTP « chunk ». Deuxièmement, on ne rajoute pas la policy APIM de « preserve-content ». Troisièmement, on envoi un fichier volumineux pour voir si on récupère bien l’intégralité du contenu.
L’APIM reçoit bien le contenu en intégralité. On peut donc en conclure que la policy « preserve-content » n’est pas utile pour la ressource APIM. Dans notre cas initial, nous devions la rajouter pour le composant Azure de Logic App.
Prenons simplement une Logic App avec un déclencheur HTTP :
Test numéro 1 : on envoie une requête HTTP basique :
Elle attend de recevoir une requête contenant un corps JSON de volume important.
La Logic App reçoit bien le corps de la requête.
Test numéro 2 : on envoie une requête HTTP « chunked » :
Comme avec notre problème initial où l’APIM recevait la requête HTTP « chunked » et la transmettait à la Logic App, on s’aperçoit qu’en recevant directement la requête, la Logic App ne parvient pas non plus à récupérer son corps.
On peut donc en conclure que c’est la ressource Azure de Logic App qui n’est pas compatible avec les requêtes HTTP « chunked ».
Tout d’abord, on créé une Azure Function simple avec un déclencheur HTTP :
[Function(FUNCTION_NAME)]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
{
var streamReader = new StreamReader(req.Body);
var body = await streamReader.ReadToEndAsync();
return new OkObjectResult(body);
}
Ce code affiche simplement la requête reçue.
Test numéro 1 : on envoie une requête HTTP basique :
Le contenu est bien affiché en sortie avec un code de statut de réponse 200 indiquant le bon fonctionnement.
Test numéro 2 : on envoie une requête HTTP « chunked » :
La sortie affiche également bien le contenu en sortie avec un code de statut de réponse 200 indiquant le bon fonctionnement.
On peut donc en conclure que les requêtes HTTP « chunked » sont compatibles avec les ressources d’Azure Function.
Ainsi, un problème rencontré à permis de mettre en avant les requêtes HTTP « chunked ». En effet, Azure ne les prends pas en charge nativement dans notre cas particulier. Il s’agit d’une requête envoyée avec l’en-tête « transfer-encoding: chunked » vers une APIM qui appelle une Logic App. On s’est alors aperçu que la Logic App ne recevait pas le corps de la requête. Il a donc fallu adapter les policies APIM afin de transmettre le corps de la requête de manière à être compatible avec la Logic App. Pour cela, nous avons utilisé « preserve-content » permettant de rassembler l’intégralité du corps de la requête avant de l’envoyer à la Logic App. Ainsi, Logic App ne reçoit cette fois plus l’en-tête « transfer-encoding: chunked » mais récupère bien le contenu. Cependant, il faut noter que l’on perd totalement, dans ce cas, les bénéfices de l’approche « chuncked ».
Une fois notre problème réglé, nous avons pu élargir l’analyse au comportement de différents composants Azure. On s’aperçoit alors que la ressource APIM en elle-même fonctionne nativement avec une requête HTTP « chunk ». Il n’y a pas besoin de rajouter la policy « preserve-content ». Lorsqu’on appelle les Logic Apps directement, sans passer par APIM, on rencontre le même problème de récupération du contenu si la requête contient un en-tête « transfer-encoding: chunked ». Le problème vient donc de cette resource spécifiquement. Enfin, les Azure Functions fonctionnent correctement en se déclenchant à partir d’une requête HTTP « chunked ».
Vous pouvez désormais utiliser vos flux en prévenant les impacts qu’une application tierce pourrait avoir en les appelant via une requête HTTP « chunked ».