Ich habe eine Verarbeitungsdatei, die die vom Benutzer gesendeten Daten verarbeitet. Zuvor vergleicht sie jedoch die Eingabe vom Client mit den erwarteten Werten, um sicherzustellen, dass sich die Daten auf der Clientseite nicht ändern.
Ich weiß zwar nicht viel über HTTP-Statuscodes, habe aber einige Nachforschungen darüber angestellt und herausgefunden, welcher Code sich am besten für die Verarbeitung unerwarteter Eingaben eignet. Dabei kam ich auf Folgendes:
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
Nun bin ich mir nicht ganz sicher, welches ich verwenden soll. Ich habe gesehen, dass „400 Bad Request“ häufig verwendet wird. Aus der Erklärung erkenne ich jedoch, dass der Fehler auf eine nicht vorhandene Anfrage und nicht auf eine ungültige Eingabe zurückzuführen ist.
Auf der anderen Seite scheint 417 Expectation Failed für meinen Zweck gerade richtig zu sein, ich habe diesen Header-Status allerdings noch nie zuvor gesehen oder ausprobiert.
Ich brauche Ihre Erfahrungen und Meinungen, vielen Dank!
Für eine vollständige Beschreibung mit Formular-/Prozessseitenentwürfen und meinen Experimenten folgen Siedieser Link.
Ergänzung: Ein weiterer Grund, warum ich dies möchte, ist, Google-Manipulationen zu verhindern. Dies wird nicht nur im Backend verwendet, sondern auch im Frontend, wo die Interaktion zwischen Gästen und Benutzern angezeigt und der Inhalt der Seite präsentiert wird.
Ich glaube*, dass die Statuscodes „200 OK“ oder „403 Forbidden“ für Seiten gültig sind, die vorhanden sind oder vorhanden sein dürfen.
*Ergänzung zwei: Ich habe mir jetzt 417 und 100 angesehen und festgestellt, dass sie dem ähneln, was ich hier zu tun versuche (zumindest nur für die Upload-Verarbeitung): http://benramsey.com/blog/2008/04/http-status-100-continue/
- dh:*Eine Webseite mit Link zur X-Site mithttp://www.example.com/page.php?query=lol&query2=failwürde von Google indexiert werden, da der HTTP-Header als OK angegeben ist.
LÖSUNG, ZU DER ICH GEKOMMEN BIN:
Tatsächlich könnte es sein, dass ich wieder bei 404 lande. Ich wollte einfach eine andere Lösung als diese, wenn HTTP sie bereitstellt, aber bisher scheint 404 immer noch die beste Lösung dafür zu sein. Vielen Dank an alle, meine Frage hat eine Antwort gefunden.
Antwort1
Wenn die Parameter für eine GET-Anfrage falsch sind, wird üblicherweise entweder eine 404-Antwort (nicht gefunden) oder eine 200-Antwort (OK) zurückgesendet.
Die RESTful-Methode zum Verwenden von GET-Anfragen besteht darin, eine Ressource abzufragen (etwas abzurufen). Wenn die erforderlichen Parameter also nicht einer vorhandenen Ressource entsprechen (weil sie unvollständig sind), können Sie genau sagen, dass die in der URI abgefragte Ressource nicht gefunden wurde.
Wenn Sie vermeiden möchten, dass Browser beispielsweise Ihre 404-Seite ignorieren und ihre eigene ersetzen (ich betrachte IE 9 und 10), sollten Sie in der Praxis 200 verwenden. Wenn Sie Ihre Anwendung als Ressource betrachten, ist 200 angemessen; Sie haben die Anwendung abgefragt und sie hat ein Ergebnis zurückgegeben (das zufällig ein Fehler war, aber nicht auf HTTP-Ebene). Diese Verwendung ist jedoch nicht sehr RESTful.
Antwort2
Der 417Fehler sollte nur auftreten, wenn der Client einen HTTP- ExpectHeader gesendet hat, den der Server nicht erfüllen konnte und der in keiner Weise mit den „erwarteten Eingaben“ der Anwendung in der Anforderung zusammenhängt. Verwenden Sie ihn nicht.
Andererseits 400sollte nur dann ein Fehler gesendet werden, wenn die HTTP-Anfrage eine fehlerhafte Syntax enthält, die der Server nicht versteht.
Keines davon ist wirklich für einen Validierungsfehler in der Anwendungslogik geeignet, obwohl es meiner Meinung nach 400etwas passender ist.
Der 403Fehler, den Sie in Ihrer Frage bei Stack Overflow in Betracht zogen, ist meiner Meinung nach die beste Option.
Ich habe gerade den Header „403 Forbidden“ verwendet, wenn die erwarteten Werte nicht im $_GET gefunden wurden, aber wenn man darüber nachdenkt, ist das nicht wirklich eine Aktion, die eine Anmeldung erfordert (nicht hierfür, natürlich muss sich ein Benutzer anmelden, um das Admin-Panel überhaupt anzuzeigen), es ist eher wie eine unerwartete Werteingabe.
Sie denken an 401, den Antwortcode, der verwendet wird, wenn eine Authentifizierung erforderlich ist. 403ist eine allgemeine Ablehnung der Anforderung, was genau nach dem klingt, was Sie wollen.
Dies alles setzt voraus, dass Sie einen Antwortcode zurückgeben möchten 4xx. Dies ist für eine API sinnvoll. Bei einer benutzerorientierten HTML-Seite möchten Sie jedoch wahrscheinlich eher eine 200mit den Fehlerinformationen im Text senden.
Antwort3
Ich kann nicht ganz herausfinden, was Sie tun, aber es gibt eine zusätzliche Option, die Sie möglicherweise nicht berücksichtigt haben – 200 – OK. Der Grund ist, dass Sie die Daten korrekt erhalten haben. Das Problem ist, dass sie für Ihre Anwendung nicht gültig sind, was kein wirkliches Problem mit dem HTTP-Protokoll ist.
Der relevante RFC istrfc2616Sie könnten 400 verwenden, aber Sie müssen dem Client dann die Möglichkeit geben, die Daten über den RFC zu ändern.
10.4.1 400 Ungültige Anfrage
Die Anfrage konnte vom Server aufgrund fehlerhafter Syntax nicht verstanden werden. Der Client SOLLTE die Anfrage NICHT ohne Änderungen wiederholen.
In Bezug auf die 417 sagt der RFC
10.4.18 417 Erwartung fehlgeschlagen
Die in einem „Expect“-Anforderungsheaderfeld (siehe Abschnitt 14.20) angegebene Erwartung konnte von diesem Server nicht erfüllt werden, oder, falls es sich bei dem Server um einen Proxy handelt, verfügt der Server über eindeutige Beweise dafür, dass die Anforderung vom Server im nächsten Hop nicht erfüllt werden konnte.
Wenn Sie also den Expect-Header nicht verwenden, sollten Sie diese Antwort wahrscheinlich nicht verwenden.