La réponse HTTP "200 OK" garantit-elle que le document a bien été reçu par la machine qui a généré la requête HTTP?
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 code HTTP 200 fonctionne-t-il également comme un accusé de réception du document?
Non pas du tout.
Cela ne garantit même pas que le document a été intégralement transmis.
Le code de réponse se trouve sur la première ligne du flux de réponses. Le serveur peut échouer ou être déconnecté du client entre l'envoi de la première ligne et le dernier octet de la réponse. Le serveur peut même ne pas savoir que cela est arrivé.
En fait, le serveur ne peut pas savoir si le client a reçu une réponse HTTP complète (ou partielle). Il n'y a aucune disposition pour un accusé de réception dans le protocole HTTP.
Désormais, vous pouvez implémenter un protocole d’application via HTTP dans lequel le client doit envoyer une seconde requête HTTP au serveur pour lui dire "oui, j’ai le document". Mais cela impliquerait une "logique d'application" implémentée 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 sur le protocole HTTP se trouve ici: http://blog.catchpoint.com/2010/09/17/anatomyhttp/
Vous devez faire la distinction entre le protocole HTTP et le protocole de transport de flux sous-jacent, qui doit être fiable pour les besoins HTTP. Le protocole de transport de flux permettra à ACKnowledge de connaître toutes les transmissions de données, y compris la réponse, de sorte que les deux extrémités de l'échange affirment que les données sont correctement transmises. Si le flux de transport échoue, vous obtiendrez une "défaillance réseau" ou une erreur similaire. Lorsque cela se produit, le protocole HTTP ne peut pas continuer. les données ne sont plus fiables ni même complètes.
Un message 200 OK signifie, au niveau HTTP, que le serveur contient le document que vous voulez et qu'il est sur le point de vous le transmettre. Normalement, vous obtiendrez également un en-tête de longueur de contenu, ce qui vous permettra de déterminer si/quand le corps est terminé en tant que vérification supplémentaire au-dessus du protocole de flux. Du point de vue du protocole HTTP, une réponse ne reçoit aucun accusé de réception. Par conséquent, une fois qu'une réponse a été envoyée, aucune vérification n'est effectuée.
Cependant, le transport de flux étant fiable, l'envoi de la réponse réussira ou entraînera une erreur. Ceci vérifie si le document a bien été reçu par la cible réseau (comme l’a noté TripeHound, dans le cas d’une connexion non directe, par exemple un proxy, ce n’est pas une garantie de livraison à la cible finale).
C'est très simple de voir que le 200 OK Le code de réponse ne garantit en rien le document de réponse. Il est envoyé avant le document est transmis, de sorte que seule une violation de causalité pourrait lui permettre de dépendre de la réussite de la réception du document. Cela sert uniquement à indiquer que la demande a été reçue correctement et le serveur estime qu'il est en mesure de répondre à la demande. Si la demande nécessite un traitement supplémentaire (par exemple, l'exécution d'un script) plutôt que de simplement renvoyer un document statique, le code de réponse doit généralement être envoyé une fois l'opération terminée. C'est donc normalement un indicateur du succès de l'opération (toutefois, dans certains cas, cela est impossible, comme les demandes avec des connexions persistantes et les 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 du problème des deux généraux . Aucun système d'accusé de réception ne peut contourner ce problème, car il doit y avoir un dernier accusé de réception; il n'y a aucun moyen de savoir si cela est reçu avec succès, car cela nécessiterait un autre accusé de réception, contredisant le principe selon lequel c'é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 dira rien si le document a été reçu par la machine qui a généré la requête HTTP =.