Classe System.Net.HttpListener

Cet article vous offre des remarques complémentaires à la documentation de référence pour cette API.

À l’aide de la HttpListener classe, vous pouvez créer un écouteur de protocole HTTP simple qui répond aux requêtes HTTP. L’écouteur est actif pendant la durée de vie de l’objet HttpListener et s’exécute dans votre application avec ses autorisations.

Pour utiliser HttpListener, créez une instance de la classe à l’aide du HttpListener constructeur et utilisez la Prefixes propriété pour accéder à la collection qui contient les chaînes qui spécifient les préfixes URI (Uniform Resource Identifier) que le HttpListener processus doit traiter.

Une chaîne de préfixe d’URI est composée d’un schéma (http ou https), d’un hôte, d’un port facultatif et d’un chemin d’accès facultatif. Un exemple de chaîne de préfixe complète est http://www.contoso.com:8080/customerData/. Les préfixes doivent se terminer par une barre oblique (« / »). L’objet HttpListener avec le préfixe qui correspond le plus étroitement à un URI demandé répond à la requête. Plusieurs HttpListener objets ne peuvent pas ajouter le même préfixe ; une Win32Exception exception est levée si un HttpListener préfixe est déjà utilisé.

Lorsqu’un port est spécifié, l’élément hôte peut être remplacé par « * » pour indiquer que les HttpListener demandes acceptent envoyées au port si l’URI demandé ne correspond à aucun autre préfixe. Par exemple, pour recevoir toutes les demandes envoyées au port 8080 lorsque l’URI demandé n’est géré par aucun HttpListener, le préfixe est http ://* :8080/. De même, pour spécifier que HttpListener toutes les demandes envoyées à un port acceptent, remplacez l’élément hôte par le caractère « + ». Par exemple : https://+:8080. Les caractères « * » et « + » peuvent être présents dans des préfixes qui incluent des chemins d’accès.

Les sous-domaines wild carte sont pris en charge dans les préfixes d’URI gérés par un HttpListener objet. Pour spécifier un sous-domaine générique carte, utilisez le caractère « * » dans le cadre du nom d’hôte dans un préfixe d’URI. Par exemple, http ://*.foo.com/. Transmettez-le en tant qu’argument à la Add méthode.

Avertissement

Les liaisons wild carte de niveau supérieur (http ://* :8080/ et http://+:8080) ne doivent pas être utilisées. Les liaisons génériques de niveau supérieur peuvent exposer votre application à des failles de sécurité. Cela s’applique aux caractères génériques forts et faibles. Utilisez des noms d’hôte explicites plutôt que des caractères génériques. Une liaison générique de sous-domaine (par exemple, *.mysub.com) ne présente pas ce risque de sécurité si vous contrôlez le domaine parent en entier (par opposition à *.com, qui est vulnérable). Consultez la rfc7230 section-5.4 pour plus d’informations.

Pour commencer à écouter les demandes des clients, ajoutez les préfixes d’URI à la collection et appelez la Start méthode. HttpListener offre à la fois des modèles synchrones et asynchrones pour le traitement des demandes clientes. Les requêtes et leurs réponses associées sont accessibles à l’aide de l’objet HttpListenerContext retourné par la GetContext méthode ou ses équivalents asynchrones, les méthodes et EndGetContext les BeginGetContext méthodes.

Le modèle synchrone est approprié si votre application doit bloquer en attendant une demande cliente et si vous souhaitez traiter une seule requête à la fois. À l’aide du modèle synchrone, appelez la GetContext méthode, qui attend qu’un client envoie une demande. La méthode retourne un HttpListenerContext objet à vous pour le traitement lorsqu’un objet se produit.

Dans le modèle asynchrone plus complexe, votre application ne bloque pas en attendant les demandes et chaque requête est traitée dans son propre thread d’exécution. Utilisez la BeginGetContext méthode pour spécifier une méthode définie par l’application à appeler pour chaque requête entrante. Dans cette méthode, appelez la EndGetContext méthode pour obtenir la demande, la traiter et répondre.

Dans l’un ou l’autre modèle, les requêtes entrantes sont accessibles à l’aide de la HttpListenerContext.Request propriété et sont représentées par HttpListenerRequest des objets. De même, les réponses sont accessibles à l’aide de la HttpListenerContext.Response propriété et sont représentées par HttpListenerResponse des objets. Ces objets partagent certaines fonctionnalités avec les HttpWebRequest objets et HttpWebResponse les objets, mais ces derniers ne peuvent pas être utilisés conjointement, HttpListener car ils implémentent le client, et non le serveur, les comportements.

Un HttpListener peut nécessiter l’authentification du client. Vous pouvez spécifier un schéma particulier à utiliser pour l’authentification, ou vous pouvez spécifier un délégué qui détermine le schéma à utiliser. Vous devez exiger une forme d’authentification pour obtenir des informations sur l’identité du client. Pour plus d’informations, consultez les propriétés et AuthenticationSchemesAuthenticationSchemeSelectorDelegate les Userpropriétés.

Remarque

Si vous créez un https à l’aide de HttpListener https, vous devez sélectionner un certificat de serveur pour cet écouteur. Dans le cas contraire, les demandes adressées échouent HttpListener avec une fermeture inattendue de la connexion.

Remarque

Vous pouvez configurer des certificats de serveur et d’autres options d’écouteur à l’aide de Network Shell (netsh.exe). Pour plus d’informations, consultez Network Shell (Netsh). L’exécutable a commencé à être expédié avec Windows Server 2008 et Windows Vista.

Remarque

Si vous spécifiez plusieurs schémas d’authentification pour l’écouteur HttpListener, l’écouteur défie les clients dans l’ordre suivant : Negotiate, NTLM, , Digestpuis Basic.

HTTP.sys

La HttpListener classe est basée sur HTTP.sys, qui est l’écouteur en mode noyau qui gère tout le trafic HTTP pour Windows. HTTP.sys fournit la gestion des connexions, la limitation de bande passante et la journalisation des serveurs web. Utilisez l’outil HttpCfg.exe pour ajouter des certificats SSL.