Ist es eine gute Übung, die Grundphrase einer HTTP-Antwort zu ändern?

Question

HTTP-Fehler haben standardisierte Antwortstrings, die ihren numerischen Codes zugeordnet sind. Z.B. 404 "Nicht gefunden" oder 500 "Interner Serverfehler". Aus der RFC ist klar, dass diese Zeichenfolgen nicht relevant für die Erkennung des Fehlers sind (nur der numerische Code ist), sondern fummelt mit z. Tornado ist klar, dass der Grund automatisch aus dem Fehlercode generiert wird, und der Grund-Parameter in der HTTPError-Klasse vorhanden ist (gemäß den Dokumenten), um nicht-standardmäßige Codes zu verwenden, was bedeutet, dass Sie im Allgemeinen nicht verwendet werden sollen.

Meine Frage ist: ist es gute Praxis, die Grundzeichenfolge zu etwas spezifischer für den tatsächlichen Fehler zu ändern, z. "500 Verbindung zur Back-End-Datenbank nicht möglich" oder "500 Festplatte ist in Flammen", oder wird diese Vorgehensweise nicht empfohlen, sollte der Fehler "500 Internal Server Error" bleiben und zusätzliche Informationen in der Nutzlast enthalten sein?

Answer 1

Nach den RFC 7230 die aktuelle Referenz für Nachrichtensyntax und Routing in HTTP/1.1, besteht der Grund Phrase mit dem alleinigen Zweck der eine Textbeschreibung mit dem numerischen Statuscode zugeordnet Bereitstellung und ein Client sollte das ignorieren Grundphrase Inhalt. Der RFC besagt auch, dass die Grundphrase leer sein kann.

Siehe das Zitat unten:

3.1.2. Status Line

Die erste Zeile einer Antwortnachricht ist die Status-Zeile, der Protokollversion bestehend, ein Raum (SP), der Statuscode, ein weiterer leerer Text, der den Statuscode beschreibt, und endend mit CRLF.

status-line = HTTP-version SP status-code SP reason-phrase CRLF 

[...]

Das Grund-Satz-Element für den alleinigen Zweck existiert mit dem numerischen Statuscode zugeordnet ist, eine textuelle Beschreibung der Bereitstellung, meist aus Rücksicht auf frühere Internet-Anwendungsprotokolle, die wurden häufiger mit interaktiven Text-Clients verwendet. Ein Client SOLLTE den Inhalt der Grundphrase ignorieren.

reason-phrase = *(HTAB/SP/VCHAR/obs-text) 

die RFC 7231 Zitiert, die aktuelle Referenz für Semantik und Inhalte für das HTTP/1.1-Protokoll:

6.1. Overview of Status Codes

[...] Die Grund-Sätze hier aufgeführten sind nur Empfehlungen - sie können durch lokale Äquivalente ersetzt werden, ohne das Protokoll zu beeinflussen. [...]

In der Theorie gibt es nichts , die Sie aus Ändern der Grund Phrase stoppt.

Allerdings sind die existing reason phrases wirklich gut bekannt und weit verbreitet. Angenommen, der Client sollte die Grundphrase ignorieren, würde ich sagen, dass es nicht korrekt ist, um die Fehlermeldung zu senden. Erwägen Sie, die Antwort-Payload dafür zu verwenden.