Der Status Code “404”: Was ist das, wofür steht es und woher kommt es?
Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
Links
- Engineering Kiosk Episode #71 Tim Berners-Lee: Was ist das World Wide Web und was ist seine Zukunft?: https://engineeringkiosk.dev/podcast/episode/71-tim-berners-lee-was-ist-das-world-wide-web-und-was-ist-seine-zukunft/
- Engineering Kiosk Episode #74 REST: Das oft falsch verstandene Architektur-Paradigma: https://engineeringkiosk.dev/podcast/episode/74-rest-das-oft-falsch-verstandene-architektur-paradigma/
- Engineering Kiosk Episode #101 Observability und OpenTelemetry mit Severin Neumann: https://engineeringkiosk.dev/podcast/episode/101-observability-und-opentelemetry-mit-severin-neumann/
- 404 Mailchimp: https://mailchimp.com/foo-404/
- 404 Lego: https://www.lego.com/de-de/foo-404
- 404 Google: https://google.com/foo-404
- 404 Figma: https://www.figma.com/404/
- 404 Code Academy: https://www.codecademy.com/404
- 404 Space Invaders: https://www.kualo.co.uk/404
- HTTP 1.0: https://datatracker.ietf.org/doc/html/rfc1945#section-6.1.1
- HTTP 1.1: https://datatracker.ietf.org/doc/html/rfc7231#section-6
- Teapot Status Code 418: https://datatracker.ietf.org/doc/html/rfc2324
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://andygrunwald.com/)
Feedback
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Buy us a coffee: https://engineeringkiosk.dev/kaffee
- Email: stehtisch@engineeringkiosk.dev
- LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
- Mastodon: https://podcasts.social/@engkiosk
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Twitter: https://twitter.com/EngKiosk
Transkript
Andy Grunwald (00:00:09 - 00:00:24)
Herzlich willkommen im Engineering Kiosk Adventskalender. Wir befinden uns im Endschwurt Türchen neunzehnte. Weihnachten selbst wird oft als das Fest der Liebe und der Familie beschrieben. Doch nicht jeder Junggeselle ist dafür bereit.
Andy Grunwald (00:00:30 - 00:00:44)
Aber in der Familie und auch in der Beziehung ist Kommunikation das A und O. Deswegen erzählt uns Wolfgang mal, wie man im Web denn so kommuniziert bzw. Wie es mal gedacht war. Wolfgang, ab ans Mikro, los geht's.
Wolfi Gassler (00:00:44 - 00:11:09)
Neulich habe ich wieder mal so eine Retrospektive mit drei Informatikerkollegen gehabt. Also so am Abend gemütlich mit einem Drink und und nach dieser Retrospektive sind wir dann bei der Bushaltestelle gestanden und einer unserer Kollegen hat auf den Bus gewartet. Nach einiger Zeit haben wir natürlich so auf welchen Bus wartest du eigentlich, damit wir auf dieser Tafel nachschauen können, wann eigentlich der Bus kommt. Und er sagt so 404. Und in der Tat, auf dieser Anzeigetafel war der Bus 404 und wir haben uns alle angeschaut und einer war der schnellste, der dann sofort gesagt hat hast du denn jemals schon gesehen in der Realität? Also da merkt man schon, wie tief eigentlich diese Zahl 404 bei uns in der Tag Szene eingebrannt ist in unseren Köpfen. Mittlerweile haben auch Endanwender immer mehr Kontakt mit der Zahl 404, also die klassische Error Seite vom HTTP Code 404, wenn etwas nicht gefunden wurde. Und ich persönlich habe ja auch lange gar nicht verstanden, dass man zusätzlich zu dem Statuscode, der auf der header Ebene gesendet wird, zusätzlich auch HTML Code senden kann oder zusätzliche Informationen. Weil für mich in den er Jahren, wo das alles angefangen hat, diese Internetgeschichte, da hat Apache einfach immer nur in dieser Serifenschrift 404 angezeigt. Not found. Und ich dachte immer, das ist alles fixiert. Und irgendwann habe ich dann auch gemerkt, man kann da Informationen senden, HTML senden und immer mehr Firmen haben das dann ausgenutzt und da hat man dann gemerkt, man kann die auch sinnvoll verwenden, diese Webseite. Also ganz klassisch liest man heutzutage du bist falsch abgebogen, es ist schön designt, es gibt paar Informationen auf dieser Webseite, also es wird da immer immer mehr gemacht. Mailchimp hat z.b. so einen kleinen Spruch auf der Webseite we lost this page, we searched high and low but couldn't find what you are looking for. Also die Firmen bemühen sich da möglichst kreativ zu sein. Lego hat oh bricks, we can't find this page. Und so Lego Männchen, die den Stecker gezogen haben. Google hingegen hat was super simples, obwohl man da ja eigentlich so die crazy Implementierung erwarten würde. Die haben einfach nur einen simplen Text und so einen broken robot, also einen Roboter, der so auseinander gebrochen ist. Es gibt aber auch komplexere Implementierungen, z.B. figma hat den 404 Text so als Vektor auf der Webseite und man kann die einzelnen Vektorpunkte und die Bezier Kurven mit der Maus verziehen und verschieben, wie in einem Grafik Editor Programm. Die Code Academy hat ein ganzes Spiel und verknüpft es natürlich auch noch mit dem Inhalt, weil die ja wirklich erklären, wie man codet und programmieren lernt. Und eine andere Webseite habe ich noch gefunden, Qualo Co. UK, hab's verlinkt in den Shownotes. Die haben einen kompletten Space Invaders implementiert, also ein geben, was man dann dort spielen kann. Ganz grundsätzlich habe ich mir natürlich überlegt, was sind eigentlich so Grundregeln, wie man so eine 404 Webseite aufbaut, wenn man sie jetzt selber macht. Also ganz wichtig meiner Meinung nach ist, dass man keine automatische Weiterleitung macht. Und das sage jetzt nicht nur ich, sondern das sagt auch Google. Also auch im SEO Sinne macht es keinen Sinn, den User einfach weiterzuleiten. Und meiner Meinung nach verwirrt man die User natürlich dann nur, wenn man plötzlich auf einer anderen Webseite landet. Im Idealfall gibt man dem User natürlich die Möglichkeit zu suchen nach dem Content, den der User braucht oder vielleicht ist der Content ja einfach nicht verfügbar. Und da hat man jetzt die Chance eigentlich die zweitausendein Attention vom User zu nutzen, weil in dem Moment ist der User geblockt, ist kurz auf Pause sozusagen. Und da kann man natürlich Informationen anzeigen, die sehr relevant sind, weil der User wahrscheinlich offen ist für alles, was in eine ähnliche Richtung geht. Also Medium, z.B. die Blogging Plattform zeigt andere Artikel an oder wenn man an den Shop denkt, wäre natürlich noch cooler, wenn man ein Spezialangebot sehen würde oder vielleicht sogar einen Spezialrabatt, weil man ja etwas nicht gefunden hat. Und von der technischen Seite, auf so 404 Seiten sieht man auch ganz oft noch so eine tracing id und eine lange NR. Wer sich dafür mal interessiert, wir haben da auch eine ganz eigene Episode gemacht, die Episode 101 über Observability zusammen mit dem Severin Neumann von Open Telemetry und da tauchen wir dann auch tiefer ein, wie man die Tracing ids verwenden kann im Code und wie man da Zusammenhänge knüpfen kann. Und um diese 404 Seite gibt es auch ganz viele Geschichten und zweitausendein Mythen, würde ich fast sagen. Also um die Herkunft von dieser 404 Seite zu erzählen, wird auch ganz oft die Geschichte genannt, dass der Serverraum in CERN, wo das Sir Tim Berners Lee, also mittlerweile ist er Sir, das HTTP Protokoll entwickelt hat und das World Wide Web eigentlich aufgebaut hat, dass diese Raumnummer 404 war. Und darum, wenn man etwas nicht finden kann, zeigt man ihm die Raumnummer 404 an. Es wäre eine super schöne Geschichte, aber leider ist sie schon öfters debunkt worden und zwar von ihm selbst. Das heißt, er persönlich hat gesagt, es stimmt nicht, es war einfach eine ganz normale Herangehensweise und man hat einfach eine Nr. Gesucht. Und ganz abgesehen davon sind die Nummern von den Räumlichkeiten im CERn auch komplett anders aufgebaut, also es macht auch keinen Sinn. Wer sich übrigens für Tim Berners Lee Mais interessiert, wir haben ihm eine ganze Episode gewidmet, weil er hat ja auch den Turing Preis erhalten und er hat nicht nur das WW erfunden, sondern hat auch im Open Data Bereich ganz viel entwickelt und forscht auch aktuell an anderen Dingen. Also gerne mal in die Episode 71 reinhören, habe ich natürlich auch in den Show Notes verlinkt. Und wie schon erwähnt, war das also eine ganz klassische Entscheidung damals. Man hat die Status Codes oder die Error Codes, wie man sie früher auch oft genannt hat, einfach machen müssen bei so einer Schnittstelle in irgendeiner Form. Und damals hat man einfach definiert, dass in der HTTP eins [sos/eos], version, alles was mit eins beginnt, ist Information, alles was zwei vorne dran hat, heißt, es war erfolgreich. Alles was mit drei beginnt, ist eine Weiterleitung. Kennen wahrscheinlich alle, die mit dem Web mehr machen. 301 ist dieses permanente Move und 302 ist dieses temporäre Move, also die Weiterleitung zu einer anderen Adresse. Wer übrigens eine gute Eselsbrücke hat, was 301 und 302 ist, bitte kommt vorbei bei uns im Discord Channel, weil ich persönlich merke mir nie, ob ich jetzt 301 oder 302 verwenden sollte. Wenn die Zahl vom Statuscode mit vier beginnt, dann haben wir einen Client Error und mit fünf haben wir einen server Fehler. Das heißt, da ist die Unterscheidung, hat der Browser, der Client, du als User etwas falsch gemacht, z.B. eine falsche Adresse, drum 404, das wäre alles mit vierte oder unauthorized kennt man auch 401, wenn man noch nicht eingeloggt ist, also alles, was auf der Client Seite liegt und die fünf, die dann sich auf die Serverseite bezieht. Und da kennen wahrscheinlich alle die er Meldung. Der internal server Error, der gilt leider für alles, man bekommt da wenig Informationen, aber auch den 502 Bad Gateway kennen vielleicht viele, gerade im Proxy Umfeld sieht man den ganz oft. Und in der HTTP eins Version hat es nur so 10 Statuscodes gegeben. In der 1. Jan. Version hat es schon eine wesentlich längere Liste gegeben, aber immer noch überschaubar. Wer sich das mal anschauen will, die RFCs sind alle unten in den Show Notes verlinkt. Aber es hat auch wirklich humorvolle Statuscodes gegeben, oder gibt es sie eigentlich immer noch? Ganz vorne dabei ist natürlich der Statuscode 418. Und zwar ist der Statuscode 418 im RFC 2324 definiert worden. Und zwar wurde der RSI offiziell am 1. Apr. 1998 definiert. Und vielleicht erahnt man schon am Datum, dass das vielleicht kein Protokoll ist, was man im realen Leben so einsetzen würde. Und zwar heißt es das Hypertext Coffee Bot Control Protocol, HDCPCB. Was übrigens interessant ist, ist, dass 1998 die Leute sich schon gewünscht haben, dass man Kaffeemaschinen fernsteuern kann, weil genau dafür ist eigentlich das Protokoll da, dass man über HTTP mit der Kaffeemaschine sprechen kann. Und interessant ist, dass dann eigentlich der Server immer 418 zurück meldet, und zwar mit dem Statuscode im A t Bot. Also ich kann nochmal zitieren aus diesem any attempt to brew coffee with a T bot should result in the arrow Code 418. I'm a teapot. Das ganze wurde übrigens 2014 nochmal erweitert um eine Kleinigkeit. Aber ein anderer Statuscode, der auch sehr nette Geschichte hat, ist der Statuscode 451 zweitausendein, der wirklich ein valider Statuscode ist, und zwar unavailable for legal reasons. Also aus rechtlichen Gründen kann der Content nicht angezeigt werden. Und das 451 ist eine Referenz auf das Buch bzw. Auf den Roman F 451. Der spielt nämlich in einem Staat, in dem es als schweres Verbrechen gilt, Bücher zu besitzen oder zu lesen. Der ist 1953 veröffentlicht worden, also da gibt es jetzt wirklich eine Story dahinter, die auch belegt ist, dass es dort eine Referenz gibt. Man merkt also schon, es gibt sehr viele Statuscodes, es gibt lustige Statuscodes, es gibt sinnvolle Statuscodes. Aber wenn man so in die Realität nach draußen schaut, dann fällt mir persönlich zumindest ganz oft auf, dass ganz viele APIs einfach immer nur den Statuscode 200 liefern und dann aber im JSON Code den Error Code drinnen haben oder eine weitere Beschreibung Ÿousand. Aber es wird eigentlich nie spezifiziert vom HTTP Statuscode. Wir haben da auch eine eigene Episode 74 gemacht über das REST Protokoll, wo wir mal wirklich in die Tiefe gehen, was man mit dem REST Protokoll alles machen kann, mit den verschiedenen Methoden, was es für Möglichkeiten gibt, auch die verschiedenen Stufen von Rest. Also da gehen wir wirklich in die Tiefe, was eigentlich möglich ist. Und es ist wirklich sehr, sehr viel möglich, sogar mit diesen alten Protokollen. Also wenn ihr mal eine API baut, bitte überlegt euch, was für Statuscodes ihr verwendet und dass dann nicht alles 200 ist. Es muss ja nicht gleich 418 sein im Teapot, aber wenigstens ein 401 für unauthorized, wenn man noch nicht eingeloggt ist, wäre ja doch ganz schön. Und ich kann euch garantieren, alle Entwickler innen werden es euch danken, wenn sie eure API verwenden. Und damit bin ich jetzt schon am Ende und werde mal probieren, ob meine mocker Maschine am Herd das htcbc Protokoll spricht zweitausendein oder ob ich doch noch persönlich Hand anlegen muss. Noch einen schönen Advent.
Andy Grunwald (00:11:09 - 00:11:33)
Danke dir Wolfgang. Wir hoffen, dass Heiligabend und Weihnachten niemals eine 404 ausspielt. Christmas not found. Wenn du aber doch it Support bei deinen Eltern an Heiligabend machen musst, leite diese Episode doch mal an deine Familie weiter. Vielleicht versteht wer den Wink mit dem 404. It support not found. Genieß die Zeit. Das war's vom Engineering Kiosk für heute. Bis zur nächsten Episode.