Gibt jede erfolgreiche HTTP-Anfrage immer den Statuscode 200 zurück?

Question

In Delphi verwende ich Indys TIdHTTPWebBrokerBridge gekoppelt mit zum Senden/Empfangen von Daten über HTTP. Auf dem Server habe ich keine schicke Handhabung, ich antworte immer nur mit einem einfachen Content-Stream. Wenn Probleme auftreten, gebe ich nur Informationen zu diesem Problem im Antwortinhalt zurück (z. B. Authentifizierung fehlgeschlagen, ungültige Anforderung usw.). Kann ich also auf der Client-Seite annehmen, dass jede erfolgreiche Anfrage, die ich an diesen Server mache, immer einen Antwortcode von 200 (OK) hat?

Ich frage mich, weil auf dem Client die Anforderungen in Funktionen verpackt sind, die nur einen Boolean für den Erfolg der Anfrage zurückgeben.

Innerhalb dieser Funktion:

IdHTTP.Get(SomeURL, AStream); 
Result:= IdHTTP.ResponseCode = 200; 

Diese Funktion verarbeitet jede und jede Anfrage, die möglicherweise Daten holen können. Wenn in der Anforderung Probleme aufgetreten sind, sollte diese Funktion False zurückgeben. In meinem Szenario, da ich immer irgendeinen Inhalt auf dem Server zurückgebe, würde der Client in dieser Funktion immer einen Antwortcode von 200 erhalten?

Ich denke, die wirkliche Frage ist, wenn ich immer eine Art von Inhalt zurückgeben und alle Ausnahmen auf dem Server behandeln, dann wird der Server immer Statuscode von 200 für jede Anfrage zurückgeben?

Answer 1

Ihre Frage zu beantworten:

kann ich davon ausgehen, dass jede erfolgreiche Anforderung ich zu diesem Server machen immer einen Antwortcode von 200 (OK) haben?

Die Antwort ist Ja, weil TIdHTTPWebBrokerBridgeTIdHTTPServer Wraps, die immer die für jede Anforderung auf 200 Standardantwortcode setzt, wenn Sie es mit einem anderen Wert selbst überschreiben, oder haben Sie Ihre Server tun etwas, das implizit antwortet mit einem anderen Antwortcode (wie Redirect(), der 302 verwendet, oder SmartServeFile(), der 304 verwendet) oder einen Fehler auftritt, der TIdHTTPServer verursacht, einen 4xx oder 5xx Fehlerantwortcode zuzuweisen.

Im Allgemeinen stimmt jedoch, was andere Ihnen gesagt haben. Auf der Clientseite sollten Sie jeden möglichen HTTP-Erfolgsantwortcode verarbeiten, nicht nur 200. Nehmen Sie keine Annahmen über die Serverimplementierung vor.

Tatsächlich behandelt bereits das für Sie. Wenn TIdHTTP einen Antwortcode feststellt, der als Fehlercode betrachtet wird, wird eine Exception EIdHTTPProtocolException in Ihrem Code ausgelöst. Wenn Sie keine Ausnahme erhalten, nehmen Sie an, dass die Antwort erfolgreich ist. Sie müssen den Antwortcode nicht manuell überprüfen.

Wenn ein bestimmter Antwortcode normalerweise eine Ausnahme auslöst, aber nicht erwünscht ist, können Sie diesen Wert im optionalen AIgnoreReplies-Parameter TIdHTTP.Get() oder TIdHTTP.DoRequest() angeben. Wenn Sie eine aktuelle Version von Indy 10 SVN verwenden, wurde der Eigenschaft TIdHTTP.HTTPOptions kürzlich ein neues hoNoProtocolErrorException-Flag hinzugefügt, sodass die EIdHTTPProtocolException-Ausnahme für keinen Antwortcode ausgelöst wird.

Answer 2

Erfolgreiche resposes ist 2xx List_of_HTTP_status_codes

Answer 3

"Hat jede erfolgreiche HTTP-Anforderung immer Statuscode 200 zurückgeben?"

Siehe w3.org: HTTP/1.1 Status Code Definitions (RFC 2616)

Die Antwort Nein ist. Alle 2xx werden als erfolgreich betrachtet. Das kann von der verwendeten HTTP method abhängen.

Sollte Ihre Web-Server-Anwendung bei Erfolg immer 200 zurückgeben? Dies kann auch von der Anfrage-Methode und dem Signal abhängen, das sie für den Kunden beabsichtigt. z.B.

für PUT Methode (Schwerpunkt ist von mir):

Wird eine bestehende Ressource geändert wird, entweder die (OK) oder (No Inhalt) Antwortcodes SOLLTE gesendet werden, um eine erfolgreiche Beendigung der Anfrage anzuzeigen.

für POST Methode:

Der von der POST-Methode durchgeführt, unter Umständen nicht in einer Ressource führen, die durch einen URI identifiziert werden kann.In diesem Fall ist (OK) oder (kein Inhalt) der entsprechende Antwortstatus, abhängig davon, ob oder nicht die Antwort eine Entität enthält, die das Ergebnis beschreibt.

Wenn eine Ressource auf dem Ursprungsserver erstellt wurde, die Antwort sollte seine (Erstellt) und eine Einheit enthalten, die den Status der Anfrage beschreibt und bezieht sich auf die neue Ressource und einen Ort Header (siehe Abschnitt 14.30). Antworten auf diese Methode sind nicht cachefähig, es sei denn, die Antwort enthält entsprechende Cache-Control- oder Expires-Headerfelder. Die (Siehe andere) Antwort kann jedoch verwendet werden, um den Benutzer-Agent angewiesen, eine zwischenspeicherbare Ressource abzurufen.

Wie Sie aus der RCF, jede Methode lernen kann seinen eigenen Erfolg Statuscodes sollten haben, abhängig von der Implementierung.

Ihre andere Frage:

„kann ich davon ausgehen, dass jede erfolgreiche Anforderung ich zu diesem Server machen immer einen Antwortcode von 200 (OK) haben wird?“

Sie können immer Statuscode 200, wenn Ihre Webserver immer antwortet mit Stand 200. Ihr Web-Server-Anwendung steuert erwarten, welche Antwort sie an den Client zurückgibt.

das gesagt ist, Statuscode 200 ist die Standard- Antwort für eine erfolgreiche HTTP-Anfragen (Die eigentliche Antwort wird auf der Anforderungsmethode abhängen verwendet) und in der realen Welt der Web-Server, sollten Sie als Standard gesetzt werden auf erfolgreiche Anfrage, sofern nicht anders angegeben (wie in Remy's answer erläutert).

Answer 4

Ich habe folgendes getan. Verarbeite alle 200`s und LOG-Ausnahmen. gearbeitet, keine einzige nicht 200 - außer Unbefugten und Timeouts (Passwort oder manchmal unavalable Server). Aber viele/alle Antworten werden für eine breite Palette von Mainstream-Apps in Betracht gezogen.

 while (iRedo < 3) do begin 
     s := Self.HTTPComponent.Get(sUrl); 

     if self.HTTPComponent.ResponseCode = 200 then begin 
      break; 
     end; 

     // IDEIA - log what happend if not 200 
     logWhatHappend(s, HTTPComponent); // then log content, headers, etc 
     inc(iRedo); sleep(5); 
     end;