Partager via


Vue d’ensemble de l’API serveur HTTP

La liste suivante identifie une séquence classique d’opérations qui utilisent l’API de serveur HTTP :

Dans les opérations qui utilisent des URL, notez que c’est l’URL traitée contenue dans le membre CookedUrl de la structure HTTP_REQUEST_V1 qui doit être utilisée. N’utilisez pas l’URL non traitées dans le membre pRawUrl , qui est uniquement à des fins de suivi et de statistiques.

Chaque application crée sa propre file d’attente de requêtes. Une application obtient son handle de file d’attente de requêtes à partir de HttpCreateHttpHandle. Il transmet ce handle à la fonction HttpAddUrl pour ajouter une URL à la file d’attente des requêtes. L’application reçoit la notification d’une requête entrante et la récupère de la file d’attente des requêtes en appelant la fonction HttpReceiveHttpRequest avec le handle de file d’attente des requêtes. Vous pouvez utiliser cette fonction pour recevoir les en-têtes de requête ou les en-têtes et le corps de l’entité. HttpReceiveHttpRequest retourne également un identificateur de demande (RequestId) pour la demande reçue qui est unique au handle de requête.

Notes

Il incombe à l’application d’examiner tous les en-têtes de requête pertinents, y compris les en-têtes de négociation de contenu s’ils sont utilisés, et d’échouer les demandes en fonction du contenu de l’en-tête. L’API serveur HTTP garantit uniquement que chaque ligne d’en-tête est correctement terminée et ne contient pas de caractères non autorisés.

 

Utilisez la fonction HttpReceiveRequestEntityBody avec le handle de file d’attente des requêtes pour récupérer les parties suivantes du corps d’entité d’une requête, le cas échéant.

Notes

L’API serveur HTTP décode les messages segmentés côté réception, mais n’effectue pas d’encodage segmenté côté envoi. Si la segmentation est requise côté envoi, l’application doit l’implémenter. Pour plus d’informations sur l’encodage segmenté, consultez RFC 2616.

 

Utilisez la fonction HttpReceiveClientCertificate avec des applications qui servent des URL à l’aide d’un schéma sécurisé (« https ») pour récupérer éventuellement les informations de certificat du client.

Les réponses sont envoyées avec la fonction HttpSendHttpResponse . Cette fonction utilise l’id de requête de la requête correspondante pour envoyer la réponse. Une réponse peut être envoyée dans plusieurs appels d’API au fil du temps en appelant la fonction HttpSendResponseEntityBody avec le RequestId de la requête reçue à l’origine.

Notes

Par défaut, HttpSendHttpResponse utilise « Microsoft-HTTPAPI/1.0 » comme en-tête « Server: ». Si une application spécifie un en-tête de serveur dans une réponse, cette valeur est placée comme première partie de l’en-tête du serveur, suivie d’un espace, puis de « Microsoft-HTTPAPI/1.0 ».

 

En général, l’API serveur HTTP masque les détails de la gestion des connexions, leur établissement et leur retrait des applications. Toutefois, une application peut éventuellement détecter l’arrêt d’une connexion en appelant HttpWaitForDisconnect.

Les applications doivent propre en procédant comme suit :

  • Lorsque l’application n’écoute pas ou ne répond pas à une URL, l’URL est supprimée à l’aide de la fonction HttpRemoveURL .
  • Lorsque l’application a terminé d’utiliser la file d’attente des requêtes, fermez le handle de file d’attente des requêtes à l’aide de la fonction CloseHandle .
  • Lorsque l’application a terminé d’utiliser l’API de serveur HTTP, appelez la fonction HttpTerminate .