HTTP-418-Fehlermeldung „I'm a teapot“

 (developer.mozilla.org)
1 Punkte von GN⁺ 2024-10-30 | 1 Kommentare | Auf WhatsApp teilen
  • HTTP 418 I'm a teapot ist ein Statusantwortcode, mit dem der Server ablehnt, Kaffee zu kochen, weil er dauerhaft eine Teekanne ist
  • Wenn eine Kombi-Kanne für Kaffee/Tee vorübergehend keinen Kaffee bereitstellen kann, sollte sie nicht 418, sondern 503 Service Unavailable zurückgeben
  • Dieser Code stammt aus dem Hyper Text Coffee Pot Control Protocol, einem Aprilscherz, und hängt mit Protokollen zusammen, die 1998 und 2014 definiert wurden
  • Ursprünglich war es ein Scherzcode aus RFC 2324, doch da er weit verbreitet ist, wurde er in RFC 9110 offiziell reserviert
  • Einige Websites verwenden 418 für Anfragen, die sie nicht wie automatisierte Abfragen behandeln möchten; in naher Zukunft kann dem Code keine nicht scherzhafte Bedeutung zugewiesen werden

Was HTTP 418 bedeutet

  • Der Statusantwortcode 418 I'm a teapot bedeutet, dass der Server das Kaffeekochen verweigert
  • Der Grund für die Ablehnung ist, dass der Server dauerhaft eine Teekanne ist
  • Wenn eine Kombi-Kanne für Kaffee/Tee vorübergehend keinen Kaffee bereitstellen kann, sollte sie 503 zurückgeben

Ein Code aus einem Aprilscherz-Protokoll

  • Dieser Statuscode verweist auf das Hyper Text Coffee Pot Control Protocol
  • Dieses Protokoll wurde 1998 und 2014 als Aprilscherz definiert
  • 418 wurde ursprünglich in RFC 2324 als Aprilscherz-Code definiert

Warum er in RFC 9110 reserviert wurde

  • Der Statuscode 418 ist als Scherz weit verbreitet und wurde deshalb in RFC 9110 offiziell reserviert
  • Aufgrund dieser Reservierung kann 418 in naher Zukunft keine nicht scherzhafte Bedeutung zugewiesen werden

Praktische Verwendung

  • Einige Websites verwenden eine 418-Antwort für Anfragen, die sie nicht verarbeiten möchten
  • Typische Beispiele sind Anfragen wie automatisierte Abfragen

Zugehörige Spezifikationen und Referenzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-30
Hacker-News-Kommentare

  • Wenn einem langweilig ist, lohnt es sich, die Diskussionen darüber zu lesen, als mnot versuchte, den Statuscode 418 aus mehreren Sprachen und Implementierungen zu entfernen, weil er technisch nicht korrekt sei
    https://github.com/nodejs/node/issues/14644
    https://github.com/golang/go/issues/21326
    Am Ende hat sogar jemand eine Website namens http://save418.com/ erstellt

    • Wenn es um 418 geht, muss ich immer an eine Auseinandersetzung bei einem früheren Arbeitgeber denken, ob man Emojis in die Anwendung einbauen sollte
      Es ging etwa darum, bei erfolgreicher Ausführung ein Raketen-Emoji anzuzeigen, und ich war dagegen. Sobald man mit so etwas anfängt, entwickeln alle eigene Vorlieben, dann gibt es ständig Diskussionen darüber, wo man mehr davon einbauen und wo man sie weglassen sollte, und selbst bei völlig anderen Themen wird es wieder hervorgeholt
      Besonders wenn man nicht per Nutzerverhaltens-Tracking prüft, ob sich reale Kennzahlen verbessern, halte ich die zusätzlichen Kommunikationskosten für einen großen Nachteil. Es war keine Frage von Professionalität, sondern diese Subjektivität – manche mögen es, manche nicht, manche bemerken es gar nicht – erzeugte immer wieder kleine Reibungen

  • Ich beantworte unberechtigte Bot-Anfragen mit 418. Das ist witzig und macht auch das Filtern der Logs einfacher
    Ein Beispiel für eine Nginx-Konfiguration sieht so aus

    Nothing to hack around here, I’m just a teapot:

    location ~* .(?:php|aspx?|jsp|dll|sql|bak)$ {
    return 418;
    }
    error_page 418 /418.html;
    Beispiel: https://FreeSolitaire.win/wp-login.php
    Zur Einordnung: /wp-login.php ist die WordPress-Login-URL, und Bots, die nach verwundbaren WordPress-Installationen suchen, fragen sie häufig blind an

  • Auch das verlinkte ursprüngliche RFC liest sich gut: https://www.rfc-editor.org/rfc/rfc2324

    • Ich mag solche RFC-Dokumente. Ich arbeite derzeit mit CCSDS-Dokumenten, und im Vergleich zu RFCs sind sie ein komplettes Durcheinander
      Wenn man Dokumentation darüber liest, wie TCP oder TLS funktionieren, hat man das Gefühl, sie sei von Fachleuten mit Erfahrung und Vision geschrieben worden; CCSDS-Dokumente dagegen wirken, als hätten Bürokraten sie verfasst, die in ihrem Leben noch keine einzige Zeile Code geschrieben haben

  • Das war ein nerdiger Non-sequitur-Witz aus der Zeit, bevor „sir, this is a wendy's“ in den 2010ern als Facebook-Meme groß wurde

    • Solche Witze gab es massenhaft, und dank xkcd gab es auch „the game“, von dem alle befreit wurden

  • Mir fällt immer wieder eine großartige Stelle ein, die ich früher einmal aus irgendeinem Grund beim Lesen des HTTP/2-RFC gefunden habe
    Bevor „429 Too Many Requests“ standardisiert wurde, gab die Twitter-API bei Rate-Limits den nicht standardisierten Statuscode 420 und den Text „Enhance Your Calm“ zurück. Aus nachvollziehbaren Gründen haben sie damit aufgehört, aber genau diese Formulierung hat es heimlich in HTTP/2 geschafft
    https://datatracker.ietf.org/doc/html/rfc7540#section-7
    Wenn man sich Eintrag 0xb ansieht, lautet der Text für das Beenden einer Verbindung wegen übermäßiger Last tatsächlich ENHANCE_YOUR_CALM. Ich muss jedes Mal lachen, wenn ich das sehe

  • Jedes Mal, wenn ich diesen Fehlercode in einem echten Dienst gesehen habe, war das sehr frustrierend
    Jemand gibt ihn zurück, um clever zu wirken, statt eines korrekten Statuscodes wie 429 oder 503, und dadurch gehen viele HTTP-Statuscode-Parser kaputt
    Es ist weder clever noch lustig, eigentlich ist es langweilig. Ich weiß, dass ich keinen Spaß verstehe, aber ich habe Arbeit zu erledigen

    • Wenn ein Parser einen Fehlercode aus der Spezifikation nicht verarbeiten kann, ist das ein Parser-Problem
    • Es gibt eine lehrreiche Anekdote, deren Wahrheitsgehalt etwas unsicher ist, die aber nahelegt: Wenn eine HTTP-Implementierung 418 übersieht, fragt man sich, was sie sonst noch übersehen hat
      Van Halen soll in seinen Konzertvertrag geschrieben haben, dass backstage M&M’s bereitstehen sollten, aber alle braunen entfernt werden müssten
      Sänger David Lee Roth erklärte in seiner Autobiografie „Crazy From the Heat“, dass das keine kindische Forderung gewesen sei, sondern ein cleverer Test, um sofort einschätzen zu können, ob ein Veranstaltungsort sicher sei
      Wenn ein Veranstaltungsort braune M&M’s bereitstellte, bedeutete das, dass der Vertrag nicht sorgfältig gelesen worden war; dann konnten auch bei gefährlicheren Punkten wie Stromversorgung oder Bühnenlast Fehler gemacht worden sein
      https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...

  • Früher hat Sonatype Nexus beim Hochladen von Artefakten einmal 418 zurückgegeben, und das war überhaupt nicht beeindruckend

    • Wenn man den Humor weglässt, frage ich mich, warum sie ausgerechnet 418 gewählt haben. Manchmal hat man das Gefühl, dass in den HTTP-Codes ein Fehler fehlt, sodass Entwickler eigene erfinden oder Codes wie 418 wiederverwenden, weil das Kollisionsrisiko gering erscheint
      Missbrauch von HTTP-Statuscodes überrascht mich jedes Mal. Mein Lieblingsbeispiel war ein Dienst eines Kunden, der „200 OK“ zurückgab und dann im Response-Body einfach nur den Text „500“ ausgab
      Als wir darum baten, bei einem API-Fehler statt 200 einen 500-Fehler zurückzugeben, änderten sie nicht den Header, sondern nur die 200 im Response. „200 Created“ ist ebenfalls ein ziemlich starkes Beispiel für mangelndes Verständnis eines Entwicklers oder seltsame Framework-Einschränkungen
    • Merkwürdig, dass das aus so einer Serious Enterprise™ Solution® kam

  • Wir verwenden in einem Authentifizierungsdienst den Antwortcode 418
    Damit unterscheiden wir, ob ein Token wegen Ablaufs ungültig ist oder aus einem anderen Grund. Bei 418 gehen wir davon aus, dass das Zugriffstoken automatisch erneuert werden kann. Das ist ziemlich harmlos und überhaupt keine Sicherheitsmaßnahme

  • Verwandte Diskussionen
    2020, 153 Punkte · 118 Kommentare: https://news.ycombinator.com/item?id=24206899
    2021, 193 Punkte · 108 Kommentare: https://news.ycombinator.com/item?id=28541327
    2023, 206 Punkte · 189 Kommentare: https://news.ycombinator.com/item?id=36090344

  • In solchen Threads verlinkt normalerweise jemand die iiNet coffee cam. Hier ist sie
    https://coffeecam.iinet.net.au/coffee/history/

    • iiNet war wahrscheinlich der beste Arbeitgeber, den ich je hatte; dort habe ich am meisten gelernt und am meisten Spaß gehabt
      Die coffeecam war auch niedlich, und acb, der hauptsächlich für die coffeecam zuständig war, verkaufte in ihrer Nähe auch amerikanische Süßigkeiten. Zumindest war das so, als ich in der Hay Street gearbeitet habe