Responsabilité du serveur http vs responsabilité de l'application Web hébergée sur ce serveur

Question

J'évalue diverses options d'hébergement pour l'application ASP.NET Core. Dans le nouveau modèle de programmation d'ASP.NET, vous traitez une requête avec un ensemble de middlewares (qui sont un mélange d'anciens IHttpModule & IHttpHandler).

Vous pouvez avoir un intergiciel qui peut être responsable de l'authentification, de la gestion des fichiers statiques ou de la compression de la réponse avant l'envoi (pour n'en nommer que quelques-uns). Voici la confusion.

Où placer une frontière entre le serveur et une application dans un contexte de responsabilité?

Quel côté devrait être responsable de en compressant la réponse? Avec IIS, cela a été géré par le serveur et configuré dans web.config. Kestrel ne fournit pas cette fonctionnalité AFAIK, donc vous devez implémenter un middleware personnalisé dans l'application qui va gérer cela pour vous. Lequel est le plus approprié?

Qu'en est-il authentification? IIS fournit des paramètres pour l'authentification (anonyme, emprunt d'identité, formulaire auth). Au contraire, dans ASP.NET Core, nous pouvons également écrire un middleware d'application qui peut gérer cela pour nous.

Ok, SSL est géré par le serveur, car il se trouve ci-dessous dans la couche de protocole et l'application fonctionne sur HTTP (S) uniquement.

Quelles sont les responsabilités du serveur? Quelles sont les responsabilités d'une application?

Answer 1

Le serveur est responsable de l'implémentation du protocole HTTP de base, gestion des connexions, etc. Il peut également choisir d'offrir d'autres fonctionnalités (par exemple windows auth), mais nous ne le recommandons pas à moins d'un avantage la mise en oeuvre. Par exemple. L'authentification Windows pourrait être implémentée dans le middleware, mais cela serait beaucoup plus difficile en raison de certaines contraintes de gestion de connexion. La compression pourrait être implémentée dans le middleware aussi facilement que dans le serveur.

Answer 2

Comme indiqué sur wikipedia:

"La fonction principale d'un serveur Web est de stocker, traiter et livrer pages Web aux clients"

La chose est que tous les célèbres serveurs http (nginx, apache, IIS, ...) viennent avec beaucoup de modules qui peuvent gérer beaucoup de tâches différentes, y compris celles que vous avez mentionnées dans votre question (authentification, compression, ...).

Il est fort probable que plus vous ajouterez de modules, plus votre serveur http sera lent. IIS, par exemple, n'est, de loin, pas connu pour être le serveur http le plus rapide, mais si vous supprimez tous les modules et l'utilisez uniquement pour servir les ressources, alors il deviendra très rapide parce que ce qu'il a été construit pour le retour dans le journées!

Le problème de la responsabilité est le même pour tous les types d'applications logicielles.
Pensez aux bases de données dont le rôle principal est de stocker des données. Les SGBDR comme Oracle ou SQL Server sont plutôt bons. Mais dès qu'ils sortent une nouvelle version, ils lancent également une nouvelle fonctionnalité qui n'a rien à voir avec le stockage des données. Et les gens l'utilisent!;-)
Combien de fois les gens ont utilisé leur DB comme moteur de recherche? J'ai vu des gens envoyer des mails avec SQL Server! Mais le pire était que certains types essayaient d'appeler les services Web dans les procédures de magasin ;-)

Il est toujours tentant d'avoir un seul outil pour tout faire, mais vous devez garder à l'esprit qu'il n'a pas été conçu pour tous les usages. Je préfère utiliser un tas d'outils légers qui ont une seule responsabilité et qui le manipulent correctement à la place.

Maintenant, revenons à votre question, je pense que c'est une bonne approche pour utiliser les middlewares. De cette façon, vous avez le contrôle sur l'ensemble du pipeline et vous savez exactement quelle a été votre demande. Les middlewares sont également testables! Se débarrasser de tous les modules inutiles va certainement vous conduire à un serveur http plus léger.

La réponse "ça dépend" est aussi acceptable. Si vous faites des tests et réalisez que le module de compression gzip est 10 fois plus rapide que le middleware, allez avec le module! Ne sois pas dogmatique non plus!