Servir des fichiers dynamiques avec Blazor dans ASP.NET –

L’une des nombreuses fonctionnalités intéressantes des frameworks tels que Blazor et ASP.NET (sur lesquels il s’exécute) est la possibilité de servir du contenu dynamique à n’importe quel point de terminaison dont votre application a besoin. Si vous souhaitez diffuser des téléchargements de fichiers générés, c’est facile à faire avec un peu de configuration.

Pourquoi servir des fichiers dynamiques ?

Fondamentalement, vous avez deux options en tant que serveur Web : répondre à une demande avec un contenu statique, comme une page HTML ou un fichier JPG, ou générer une réponse personnalisée à envoyer à l’utilisateur. Blazor fonctionne sur ASP.NET, donc le serveur HTTP intégré prend en charge un large éventail d’options et permet une grande flexibilité.

Par exemple, vous souhaitez peut-être héberger un fichier JSON sur /images/pathname.json. Il n’est pas nécessaire que ce soit un fichier littéral sur le disque ; le serveur peut interpréter cette requête et répondre avec tout type de contenu, y compris quelque chose d’inattendu comme un fichier PNG. Vous pouvez répondre à cette demande en récupérant des résultats à partir d’une API, en construisant une réponse et en renvoyant la chaîne à l’utilisateur.

Ou peut-être souhaitez-vous générer le fichier réel à la volée. Par exemple, il existe de nombreuses bibliothèques graphiques utilisées pour dessiner des images personnalisées. Vous pouvez utiliser l’un d’eux pour générer une image et répondre à la demande de l’utilisateur avec les données, le tout en mémoire.

Dans ce dernier cas, il peut être judicieux de mettre en cache la réponse en la sauvegardant sur disque et en répondant la plupart du temps avec un vrai fichier. Cela peut être utile pour les générations de fichiers gourmandes en ressources qui ne changent pas si souvent.

Configuration

Servir des fichiers comme celui-ci est intégré et assez simple à faire. Vous devrez créer une nouvelle page Razor, sur laquelle Blazor s’exécute. Vous pouvez le faire en cliquant avec le bouton droit dans Visual Studio et en sélectionnant Ajouter > Page Razor.

Cela crée deux fichiers qui sont liés l’un à l’autre dans la hiérarchie : Name.cshtml, qui gère le côté HTML des choses, et Name.cshtml.cs, qui gère le modèle et le code réel. Comme il ne s’agira pas d’une véritable page Web, mais simplement d’un fichier, vous pouvez ignorer le premier pour la plupart.

Vous devrez cependant régler le @page attribut correspondant à l’endroit où vous souhaitez que ce fichier soit hébergé. Vous voudrez probablement inclure des caractères génériques, ce que vous faites avec des crochets.

Dans le Name.cshtml.cs fichier, vous verrez du code réel s’étendre PageModel. La fonction principale ici est OnGet(), que vous voudrez probablement changer en OnGetAsync() si vous effectuez un traitement asynchrone.

Vous avez trois options principales à partir de cette fonction. Premièrement, retourne un PhysicalFile, qui lit littéralement un fichier sur le disque avec un chemin donné, et l’envoie à l’utilisateur avec un type, éventuellement avec un nom de téléchargement différent du chemin réel.

Bien que vous soyez probablement ici pour générer quelque chose de manière dynamique, cela peut être très utile pour la mise en cache. Si votre fonction de traitement enregistre le résultat dans un fichier, vous pouvez vérifier si ce fichier existe avant de le traiter à nouveau, et si c’est le cas, renvoyer simplement la réponse mise en cache.

L’option suivante renvoie un fichier virtuel, étant donné un tableau d’octets. C’est ce que vous voudrez utiliser pour la plupart des applications, car il fonctionne entièrement en mémoire et devrait être très rapide.

Selon l’encodage que vous essayez d’utiliser, vous souhaiterez peut-être convertir une chaîne en un tableau d’octets à l’aide de la Encoding classe d’aide.

Encoding.UTF8.GetBytes(string);

Enfin, vous pouvez renvoyer directement une chaîne de contenu, ce que vous devez utiliser si vous souhaitez afficher le contenu à l’utilisateur plutôt que de déclencher un téléchargement dans son navigateur.

Il existe d’autres options que ces trois, mais le reste implique de répondre avec des codes d’état, de rediriger, de réponses non autorisées et de rendre la page elle-même.

Servir des fichiers en fonction des routes et des paramètres

Bien sûr, rien de tout cela n’est utile si vous ne pouvez pas répondre aux demandes basées sur les entrées de l’utilisateur. Les deux formes d’entrée sont toutes les deux dans l’URL : les paramètres de routage et les paramètres d’URL. Les paramètres de routage correspondent à ce que vous avez spécifié à l’aide de caractères génériques dans la page elle-même et constituent le chemin d’accès réel au fichier. Les paramètres d’URL sont facultatifs.

Comprendre cela peut être un peu pénible, mais heureusement, vous avez un débogueur à vos côtés, vous pouvez donc définir un point d’arrêt dans OnGetAsync() et afficher l’intégralité de l’arbre des variables locales.

Vous trouverez, sous this.PageContext.RouteData, il y a un RouteValueDictionary<string, object> qui stocke tous les itinéraires. Notez que cela inclut la route de la page elle-même, donc si vous avez utilisé /Download/{param} comme route, le param sera la deuxième option.

La meilleure façon de récupérer les paramètres est de les rechercher par clé :

De même, les paramètres de requête sont également disponibles, mais à partir d’un objet différent. Vous devrez accéder HttpContext.Request.Query, qui est un QueryValueDictionary contenant les paramètres d’URL, et fonctionne de la même manière que celui de la route.

Vous êtes alors libre d’utiliser ces paramètres pour effectuer des recherches ou affecter la logique. Cependant, si vous mettez en cache des réponses, vous voudrez vous assurer que vos conditions de cache et vos recherches sont également affectées par ces paramètres, ou vous pourriez rencontrer des problèmes avec des comportements de mise en cache inattendus.