Code d'état HTTP 100
100 (Continuer) Le demandeur doit continuer à faire sa demande. Le serveur renvoie ce code pour indiquer qu'il a reçu la première partie de la requête et attend le reste.
Le serveur détermine s'il doit accepter la demande du client en fonction de l'en-tête de la demande du client. Si la demande est acceptée, il répond avec un code d'état 100. Le serveur détermine s'il s'agit d'une requête Expect en fonction de l'existence ou non d'un en-tête de requête Expect: 100-continue (certains serveurs Web ne peuvent pas gérer correctement les requêtes Expect). indique que le serveur a reçu la partie initiale de la requête et demande au client de continuer l'envoi. Une fois que le serveur a envoyé le code d'état 100 Continue, il doit répondre s'il reçoit une demande du client.
Ce code d'état est en fait une optimisation pour le scénario suivant : le client a un fichier plus volumineux qui doit être téléchargé et enregistré, mais le client ne sait pas si le serveur est prêt à accepter le fichier, il espère donc le transférer. avant de consommer les ressources du réseau, demandez d'abord ses souhaits au serveur. L'opération réelle consiste pour le client à envoyer un message de demande spéciale, et l'en-tête du message doit contenir
Expect: 100-continue
À ce moment, si le serveur est prêt à l'accepter, il renverra un code d'état 100 Continuer, sinon il le fera renvoie un code d'état 417 Expectation Failed. Pour le client, si le client n'a pas l'intention d'envoyer une requête réelle, il ne doit pas envoyer de message contenant 100 Continue Expect, car cela ferait croire à tort au serveur que le client est sur le point d'envoyer une requête.
Comme mentionné précédemment, toutes les applications HTTP ne prennent pas en charge le code d'état 100 Continue (comme HTTP/1.0 et les versions précédentes de proxys ou de serveurs), le client ne doit donc pas attendre la réponse du serveur après l'envoi de 100 Continue Expect , après un. pendant un certain laps de temps, le client doit envoyer directement le contenu dont l'envoi est prévu.
Quant au serveur, 100 Continue ne doit pas être considéré comme une méthode de jugement strict. Le serveur peut avoir reçu le corps du message du client avant d'envoyer la réponse. À ce stade, le serveur n’a plus besoin d’envoyer 100 Continue en réponse. Mais vous devez toujours renvoyer le code d'état approprié une fois l'acceptation terminée. En théorie, lorsque le serveur reçoit une requête 100 Continue Expect, il devrait répondre. Mais le serveur ne doit jamais envoyer de code d'état 100 Continue en réponse à un client qui n'a pas envoyé de requête 100 Continue Expect. La réponse mentionnée ici signifie : en supposant que le serveur n'a pas l'intention de recevoir le corps du message à envoyer par le client, il doit également émettre une réponse appropriée (comme l'envoi de 417 Expectation Failed) au lieu de simplement fermer la connexion, ce qui entraînera problèmes pour le client. Impact au niveau du réseau.
En particulier, l'application HTTP en tant que proxy doit faire des jugements supplémentaires lors de la réception d'une demande avec 100 Continue Expect. En supposant que le serveur proxy sait clairement que la version HTTP en aval du message est compatible avec HTTP/1.1, ou que le serveur proxy ne connaît pas la version en aval du message, il doit transmettre cette requête 100 Continue Expect. Cependant, si le serveur proxy sait clairement que l'application en aval du message ne peut pas gérer 100 Continue Expect, il doit directement renvoyer 417 Expectation Failed au client en réponse. Et ce n'est pas la seule solution. Une autre méthode possible consiste à renvoyer directement 100 Continue au client, puis à transmettre le message avec 100 Continue Expect supprimé en aval.
De plus, si le serveur proxy décide de servir HTTP/1.0 et les versions précédentes, alors lorsqu'il reçoit le message de réponse 100 Continue du serveur, il ne doit pas transmettre cette réponse au client, car le client est susceptible de ne pas le faire. Je ne sais pas comment gérer ce message.
