Requests: 418 Ich bin eine Teekanne

Übrigens, ich bin mir bewusst, dass dies eine bahnbrechende Änderung ist; das Verwerfen und Verzögern auf die nächste Hauptversion ist in Ordnung.

Betreffende Codezeile: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

Bitte beachten Sie die alternativen Versionen für 200 OK: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

Hm. Das einzige, was mir dort Sorgen bereitet, ist die Verwendung von Unicode und Backslashes; Anfragen geben diese nicht aus, oder?

Nein, dies ist nur für die Rückwärtssuche gedacht – das gleiche gilt für Ich bin eine Teekanne.

Ok das ist gut. Das Problem ist, dass die Implementierung als Beweis verwendet wird, um die tatsächliche Verwendung des Statuscodes auszuschließen, was _eventuell_ ein Problem sein wird.

Informationen zu ähnlichen Änderungen finden Sie unter https://github.com/nodejs/node/issues/14644 und https://github.com/golang/go/issues/21326 .

Ich bin damit einverstanden, es zu entfernen, es sei denn, wir möchten andere Statuscodes wie 420 und Freunde hinzufügen.

HTTPbin.org behält es aber :)

Einzelne Server machen mir weniger Sorgen :)

Senden Sie eine PN!

Machen Sie es jedoch gegen den 3.0.0-Zweig, dies wird eine bahnbrechende Änderung sein.

Festhalten! Ich bin der Typ hinter http://save418.com (https://github.com/WhataShane/save418). Ich stolpere, wie viele andere auch , gerne über (fast) harmlose Gags wie 418. So etwas zaubert einem selbst dann ein Lächeln ins Gesicht, wenn man unter Druck steht, einen Projekttermin einzuhalten und der Chef einen ankläfft ein Büro vorbei. Es wäre wirklich schade, wenn es gehen würde.

Um @romellem aus dem Go-Thread zu zitieren, der das Argument für 418 recht eloquent zusammenfasst:

Nur um es klar zu sagen, ist Ihr Argument, dass wir, wenn der 400-Block aufgebraucht ist, diesen einen zusätzlichen Code zur Verfügung haben wollen, um die Nützlichkeit des 400-Blocks noch ein bisschen weiter auszudehnen?

Sofern ich es nicht falsch lese, sind für den 400-Block von HTTP-Statuscodes mehr als 50 Codes verfügbar. Bei einem verfügbaren "Platz" des 400er-Blocks von mehr als 50% kann dies eine vorzeitige Optimierung für ein Problem sein, das möglicherweise nie auftritt (das heißt, dem 400-Block gehen die verfügbaren Codes aus).

Ich versuche nicht, hart zu klingen, aber ich mag lustige kleine Ostereier, die man während einer Programmierkarriere findet. Für mich zeigt es, dass alles, was dazu führt, dass ein Computer tatsächlich funktioniert, immer noch von Menschen gemacht wird, und es ist schön, kleine Teile dieses menschlichen Elements zu behalten (meiner Meinung nach). Ihr Argument ist stichhaltig und logisch, aber diese angeforderte Änderung verringert den "Spaß" von Go (und möglicherweise NodeJS) im Sinne der technischen Robustheit ein wenig. Am Ende des Tages muss ich sagen, dass sich dieser Kompromiss nicht lohnt.

(Ich schätze die Geschichtsstunde jedoch! Ich dachte immer, 418 sei ein Teil der HTTP/1.x-Spezifikation; wusste nichts von der "HTCPCP/1.0"-Spezifikation. 🙂)

Ich stimme zu, dass es ein lustiges Osterei ist.

Anfragen nimmt sich selbst ernst, aber nicht zu ernst. :)

Dies könnte die Zeile von "zu ernst" sein.

Ist es hier nicht die offensichtliche Antwort, es in die Spezifikation aufzunehmen, indem man mit einem neuen RFC beginnt?

@tSavo Ganz klar!

Obwohl ich erkenne, dass 418 nicht Teil der HTTP-Statuscode-Spezifikation in RFC 7231 ist, existiert es in freier Wildbahn. Sogar Google hat es hier implementiert. Für den unwahrscheinlichen Fall, dass die IETF beschließt, eine echte Verwendung für 418 zu implementieren, werden wir eine Menge Vorwarnungen haben, um dies anzugehen. Ich bin dafür, dies so zu belassen, wie es ist, es sei denn, es gibt einen zwingenderen Grund, warum es entfernt werden muss.

Gib mir deine Schlüssel.

Nur um das klarzustellen, ich stimme dem Rest des Requests-Teams zu: Wir sollten das 418-Mapping hier behalten. Aber der Grund , warum ich einverstanden ist rein pragmatisch, nicht wegen des Spaßes Osterei (obwohl es Spaß ist): codes.py verwendet wird , eine Abbildung von Grunde Begriff Code zu bauen. Aus diesem Grund sollte es jede Begründungsphrase enthalten, die mit einiger Wahrscheinlichkeit für einen bestimmten Code auftaucht. Im Moment bin ich eine Teekanne. Wenn sich dies ändert, fügen wir jeden anderen Satz hinzu, den die IANA zuweist.

@mnot , Sie können diese Antwort gerne wiederverwenden und nicht in unserem Namen blockieren sollte. 😉 Ich finde Vernunftphrasen sowieso blöd.

Ein Antrag auf Registrierung von 418 wurde bei der IANA unter der Nummer 979050 eingereicht.

In Ordnung; Dies ist kein Diskussionsforum für die Verdienste von 418. @mnot Wenn Sie dies verfolgen möchten,