J'ai deux machines, A et B.
A envoie une requête HTTP à B et demande un document. B répond, envoie le document demandé et envoie un message 200 OK, mais la machine A se plaint du fait que le document n’a pas été reçu en raison d’une défaillance du réseau.
Le code HTTP 200 fonctionne-t-il également comme accusé de réception du document?
Le HTTP 200, le code du travail comme une reconnaissance du fait que le document a été reçu?
Pas de. Pas du tout.
Il n'est même pas une garantie que le document a été complètement transmises.
Le code de réponse est dans la première ligne du flux de réponse. Le serveur risque d'échouer ou d'être déconnecté du client n'importe où entre l'envoi de la première ligne et le dernier octet de la réponse. Le serveur ne peut pas même savoir ce qui s'est passé.
En fait, il n'y a aucun moyen que le serveur peut savoir si le client a reçu une complète (ou partielle) de la réponse HTTP. Il n'y a pas de disposition pour un accusé de réception dans le protocole HTTP.
Vous pouvez maintenant mettre en œuvre un protocole d'application sur le dessus de HTTP dans lequel le client est tenu d'envoyer une deuxième requête HTTP vers le serveur de dire "oui, j'ai reçu le document". Mais cela impliquerait une certaine "logique de l'application", mis en œuvre dans le navigateur de l'utilisateur; par exemple en Javascript.
Absolument pas. HTTP 200 est généré par le serveur et signifie seulement qu'il a compris la demande et pense pouvoir y répondre (par exemple, le fichier est réellement là). Toutes sortes d'erreurs peuvent se produire lors de la transmission du document de réponse complet (rupture de la connexion réseau, perte de paquets, etc.) qui n'apparaîtront pas dans la réponse HTTP, mais devront être détectées séparément.
Un très bon guide pour le protocole HTTP est disponible ici: http://blog.catchpoint.com/2010/09/17/anatomyhttp/
Vous devriez faire une distinction entre le protocole HTTP et le flux sous-jacent protocole de transport, qui doivent être fiables pour HTTP fins. Le flux de protocole de transport accusons réception de toutes les données de transmission, y compris la réponse, de sorte que les deux extrémités de l'échange permet d'affirmer que les données sont transmises correctement. Si le flux de transport échoue, alors vous obtiendrez un réseau d'échec ou d'erreur similaire. Lorsque cela se produit, le protocole HTTP ne peut pas continuer; les données ne sont plus fiables, voire complète.
Quel message 200 OK moyens, au niveau HTTP, c'est que le serveur a le document que vous êtes après, et est sur le point de le transmettre à vous. Normalement vous recevrez un contenu en-tête de longueur, de sorte que vous serez en mesure de vérifier si/quand le corps est complet comme un contrôle supplémentaire sur le dessus du protocole de flux. À partir du protocole HTTP perspective, une réponse reçoit pas d'accusé de réception, pour une fois qu'une réponse a été envoyée il n'y a pas de vérification.
Cependant, comme le flux de transport est fiable, la loi de l'envoi de la réponse sera soit un succès ou une erreur. Ce n'vérifier si le document a été reçu par le réseau de la cible (comme indiqué par TripeHound, dans le cas de non-connexion directe, par exemple un proxy, ce n'est pas une garantie de livraison à l'objectif final).
Il est très simple de voir que l' 200 OK code de réponse ne peut pas être une garantie de quoi que ce soit sur le document de réponse. Il est envoyé avant que le document est transmis, de sorte que seule une violation de la causalité pourrait lui permettre d'être dépend de la réussite de la réception du document. Il ne sert que d'indicateur que la demande a été reçue correctement et le serveur croit qu'il est en mesure de satisfaire la demande. Si la demande nécessite un traitement supplémentaire (par exemple, l'exécution d'un script), plutôt que de simplement retourner un document statique, le code de réponse devrait généralement être envoyée après que cela a été terminé, il est donc normalement un indicateur que ce fut un succès (mais il y a des situations où cela n'est pas possible, notamment pour des demandes avec les connexions persistantes et des notifications push -- le script pourrait échouer plus tard).
Sur un plan plus général, il n'est jamais possible de fournir une garantie absolue que tous les messages ont été reçus dans n'importe quel protocole, en raison de la Deux Généraux de Problème. Aucun accusé de réception n'système peut contourner ce problème, parce qu'à un certain moment, il y a un dernier accusé de réception; il n'y a aucun moyen de savoir si c'est correctement reçu, parce que cela nécessiterait un autre accusé, en contradiction avec le principe qu'il était le dernier.
HTTP est conçu avec une conscience de la possibilité de différentes sortes de "boîtiers" - des mandataires fonctionnant avec ou sans la connaissance du client.
Si un proxy est impliqué, le simple fait de savoir que le serveur a transmis toutes les données et reçu une connexion rapprochée normale ne vous permet pas de savoir si le document a été reçu par la machine qui a généré la demande HTTP .
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
