HTTP 100-Statuscode

100 (Weiter) Der Anforderer sollte mit der Anfrage fortfahren. Der Server gibt diesen Code zurück, um anzuzeigen, dass er den ersten Teil der Anfrage erhalten hat und auf den Rest wartet.

Der Server bestimmt anhand des Anforderungsheaders des Clients, ob er die Anfrage des Clients annimmt. Wenn die Anfrage angenommen wird, antwortet er mit einem 100-Statuscode. Der Server bestimmt, ob es sich um eine Expect-Anfrage handelt, basierend darauf, ob ein Expect: 100-continue-Anfrageheader vorhanden ist (einige Webserver können Expect-Anfragen nicht korrekt verarbeiten)

Dieser Statuscode zeigt an, dass der Server den ersten Teil der Anfrage erhalten hat und der Client aufgefordert wird, mit dem Senden fortzufahren. Nachdem der Server den 100 Continue-Statuscode gesendet hat, muss er antworten, wenn er eine Anfrage vom Client erhält.

Dieser Statuscode ist eigentlich eine Optimierung für das folgende Szenario: Der Client hat eine große Datei, die hochgeladen und gespeichert werden muss, aber der Client weiß nicht, ob der Server bereit ist, die Datei zu akzeptieren, also tut er es hofft, das Netzwerk zu verbrauchen. Bevor Sie Ressourcen übertragen, fragen Sie den Server nach seinen Wünschen. Der eigentliche Vorgang besteht darin, dass der Client eine spezielle Anforderungsnachricht sendet. Wenn der Server zu diesem Zeitpunkt bereit ist, diese zu akzeptieren, wird der Statuscode 100 zurückgegeben Andernfalls wird der Status „417 Expectation Failed“ zurückgegeben. Wenn der Client nicht beabsichtigt, eine tatsächliche Anfrage zu senden, sollte er keine Nachricht mit 100 Continue Expect senden, da der Server dadurch fälschlicherweise annimmt, dass der Client im Begriff ist, eine Anfrage zu senden.

Wie bereits erwähnt, unterstützen nicht alle HTTP-Anwendungen den Statuscode „100 Continue“ (z. B. HTTP/1.0 und frühere Versionen von Proxys oder Servern), daher sollte der Client nicht weiterhin „100 Continue Expect“ senden, nachdem er auf den Server gewartet hat Als Antwort sollte der Kunde nach einer bestimmten Zeitspanne direkt den für den Versand geplanten Inhalt senden.

Was den Server betrifft, sollte 100 Continue nicht als strenge Beurteilungsmethode angesehen werden. Möglicherweise hat der Server die Textnachricht vom Client erhalten, bevor er die Antwort gesendet hat. Zu diesem Zeitpunkt muss der Server nicht mehr 100 Continue als Antwort senden. Nach Abschluss der Annahme muss jedoch immer noch der entsprechende Statuscode zurückgegeben werden. Theoretisch sollte der Server antworten, wenn er eine 100 Continue Expect-Anfrage erhält. Der Server sollte jedoch niemals den Statuscode „100 Continue“ als Antwort auf einen Client senden, der keine Anfrage „100 Continue Expect“ gesendet hat. Die hier erwähnte Antwort bedeutet: Angenommen, der Server beabsichtigt nicht, die vom Client zu sendende Textnachricht zu empfangen, sollte er auch eine entsprechende Antwort geben (z. B. das Senden von 417 Expectation Failed), anstatt einfach die Verbindung zu schließen, was dazu führt Probleme für den Client.

Insbesondere muss die HTTP-Anwendung als Proxy zusätzliche Beurteilungen vornehmen, wenn sie eine Anfrage mit 100 Continue Expect empfängt. Unter der Annahme, dass der Proxyserver eindeutig weiß, dass die HTTP-Version, die der Nachricht nachgeschaltet ist, mit HTTP/1.1 kompatibel ist, oder dass der Proxyserver die Downstream-Version der Nachricht nicht kennt, sollte er diese 100 Continue Expect-Anfrage weiterleiten. Wenn der Proxyserver jedoch eindeutig weiß, dass die der Nachricht nachgeschaltete Anwendung 100 Continue Expect nicht verarbeiten kann, sollte er direkt 417 Expectation Failed als Antwort an den Client zurückgeben. Und das ist nicht die einzige Lösung, die darin besteht, 100 Continue direkt an den Client zurückzugeben und die Nachricht dann mit 100 Continue Expect gelöscht an den Downstream weiterzuleiten.

Wenn der Proxyserver außerdem beschließt, HTTP/1.0 und frühere Versionen bereitzustellen, sollte er diese Antwort nicht an den Client weiterleiten, wenn er eine 100 Continue-Antwortnachricht vom Server empfängt, da der Client höchstwahrscheinlich weiß nicht, was er mit der Nachricht anfangen soll.