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?

Le code HTTP 200 fonctionne-t-il également comme un accusé de réception du document?

Non pas du tout.

Ce n’est même pas une garantie que le document a été complètement transmis.

Le code de réponse se trouve sur la première ligne du stream de réponses. Le serveur pourrait échouer ou ê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 peut même ne pas savoir que cela s’est produit.

En fait, le serveur ne peut en aucun cas 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.

Maintenant, vous pouvez implémenter un protocole d’application au-dessus de HTTP dans lequel le client doit envoyer une deuxième requête HTTP au serveur pour lui dire “oui, j’ai reçu 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 uniquement qu’il a compris la requête et pense pouvoir y répondre (par exemple, le fichier est réellement présent). Toutes sortes d’erreurs peuvent survenir lors de la transmission du document de réponse complet (rupture de la connexion réseau, perte de paquets, etc.) qui n’apparaît pas dans la réponse HTTP, mais doit être détectée séparément.

Un bon guide du protocole HTTP est disponible ici: http://blog.catchpoint.com/2010/09/17/anatomyhttp/

Vous devez faire une distinction entre le protocole HTTP et le protocole de transport de stream sous-jacent, qui devrait être fiable à des fins HTTP. Le protocole de transport de stream reconnaîtra toutes les transmissions de données, y compris la réponse, de sorte que les deux extrémités d’échange reconnaissent que les données sont transmises correctement. Si le stream de transport échoue, vous obtiendrez une erreur de réseau ou une erreur similaire. Lorsque cela se produit, le protocole HTTP ne peut pas continuer; les données ne sont plus fiables ou même complètes.

Qu’est-ce qu’un message 200 OK signifie, au niveau HTTP, que le serveur possède le document que vous recherchez et est sur le sharepoint vous le transmettre. Normalement, vous obtiendrez également un en-tête de longueur de contenu, vous pourrez donc vérifier si / quand le corps est complet en tant que vérification supplémentaire par-dessus le protocole de stream. Du sharepoint vue du protocole HTTP, une réponse ne reçoit aucun accusé de réception, de sorte qu’une fois qu’une réponse a été envoyée, il n’y a pas de vérification.

Cependant, comme le transport de stream est fiable, l’envoi de la réponse sera soit réussi, soit une erreur. Cela permet de vérifier si le document a été reçu par la cible du réseau (comme indiqué par TripeHound, dans le cas d’une connexion non directe, par exemple un proxy, cela ne garantit pas la livraison à la cible finale).

HTTP est conçu avec la conscience de la possibilité de différentes sortes de «boîtes médianes» – des proxies fonctionnant avec ou sans la connaissance du client.

S’il y a un proxy impliqué, alors même en sachant que le serveur a transmis toutes les données et reçu une connexion étroite normale, cela ne vous dirait rien si le document a été reçu par la machine qui a généré la requête HTTP .

Il est très simple de voir que le code de réponse 200 OK ne peut en rien garantir le document de réponse. Il est envoyé avant la transmission du document, de sorte que seule une violation de la causalité pourrait lui permettre de dépendre de la réception du document. Il sert uniquement d’indicateur indiquant que la demande a été correctement reçue et que le serveur estime pouvoir répondre à la demande. Si la requête nécessite un traitement supplémentaire (par exemple, exécuter un script), plutôt que de renvoyer un document statique, le code de réponse doit généralement être envoyé une fois celui-ci terminé. n’est pas faisable, comme les requêtes 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 un 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 a été reçu avec succès, car cela nécessiterait un autre accusé de réception, ce qui contredit le postulat que c’était le dernier.

A envoie une requête à B. Il peut y avoir toutes sortes d’obstacles empêchant la requête d’atteindre B. Dans le cas de https, la requête peut atteindre B mais être rejetée et elle compte comme si elle n’avait pas atteint B. Dans tous ces cas, B n’enverra aucun statut.

Une fois que la requête atteint B, et qu’il n’y a pas de bogue qui tombe en panne, ni de défaillance matérielle, etc. B examinera la demande et déterminera quoi faire et quel statut signaler. Si A demande un fichier qui est là et que A est autorisé à y accéder, B commencera à envoyer un “statut 200” avec les données du fichier.

Encore une fois, toutes sortes de choses peuvent mal tourner. A peut ne rien recevoir, ou “statut 200” sans données ou données incomplètes, etc. (Par “recevoir”, je veux dire que les données arrivent sur le câble Ethernet ou via le WiFi).

Habituellement, l’utilisateur de A utilisera une bibliothèque qui gère les bits laids. Avec une bibliothèque décente, l’utilisateur peut s’attendre à recevoir une erreur ou un état complet avec les données correspondantes. Si un statut 200 arrive à A avec seulement la moitié des données, l’utilisateur recevra (en fonction de la conception de la bibliothèque) une erreur, pas un statut et certainement pas un statut 200.

Ou bien vous pouvez avoir une bibliothèque qui indique le statut 200 et vous indique “voici les 2 000 premiers octets”, “voici les 2 000 octets suivants” et ainsi de suite. était une erreur, les données sont incomplètes “.

Mais en général, le cas où l’utilisateur obtient un statut 200, et aucune donnée, ne se produira pas.