Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › HTTP Error 418: Fehlercode "Ich bin…

Begründung falsch?

  1. Thema

Neues Thema Ansicht wechseln


  1. Begründung falsch?

    Autor: Bluejanis 13.08.17 - 14:35

    Soweit ich weiß gibt es bei HTTP-Codes bisher keine Knappheit und es gibt genug freie Codes. Ein Problem sehe ich dort nicht.

    So spaßig ein uralter Scherz auch ist. Ich finde sowas hat in offiziellen Implementierungen, die eigentlich seriös sein wollen, nichts zu suchen.

    Ich hab nichts gegen Scherze, aber bitte nicht in irgendwelchen Spezifikationen! Das macht es für Neulinge doch nur verwirrend und unübersichtlich. Oder soll man wirklich Zeit verschwenden und bei jedem Feature wirklich gucken, ob es ernst gemeint ist. Müssen wir wirklich alle Altlasten aus alten Technikzeiten beibehalten?

    Das ist zumindest meine Meinung. Wie seht ihr das?
    Vielleicht bin ich als professioneller Softwareentwickler auch vorbelastet und möchte möglichst sauberen Code haben, der auch gut wartbar bleibt. Manchmal ist das schwerer die Grenze zu erkennen, aber in Code gehört nichts überflüssiges rein.



    1 mal bearbeitet, zuletzt am 13.08.17 14:38 durch Bluejanis.

  2. Re: Begründung falsch?

    Autor: maverick1977 13.08.17 - 14:49

    Bin ganz deiner Meinung. Ein Scherz, der ewig mit rumgeschleppt wird, bei dem wohl nicht nur mir der Spaßfaktor definitiv fehlt, ist irgend wie totaler Schwachsinn. Braucht kein Mensch und ist total bekloppt.

    Dazu noch die Frage, was dieser Status-Code dem Besucher sagen soll, außer dass der Betreiber gerne mit alten Gecks um sich schmeißt, während Besucher auf der Seite etwas sinnvolles erwartet.

  3. Re: Begründung falsch?

    Autor: blariog 13.08.17 - 15:09

    Ich verstehe deine Argumentation nicht.
    Wenn du den Code auf deinem Server nicht implementierst, wird er nie zu Geltung kommen. Er steht nur in den offiziellen Dokus, sonst nirgendwo. Und es wird eventuell mal ein Server nebst Anwendung so konfiguriert, dass der Fehler geschmissen wird.

    Btw. auch ich war mehr als 10 Jahre Entwickler und mag sauberen Code. Aber wenn du dir mal die Spec/RFC für E-Mail-Adressen anschaust und prüfst, wie viele du von denen in deiner Anwendung bauen kannst, die kein Mailserver versendet, dann weißt du, was Overhead in Specs wirklich ist...

  4. Re: Begründung falsch?

    Autor: janoP 13.08.17 - 15:35

    Bluejanis schrieb:
    --------------------------------------------------------------------------------
    > Soweit ich weiß gibt es bei HTTP-Codes bisher keine Knappheit und es gibt
    > genug freie Codes. Ein Problem sehe ich dort nicht.
    >
    > So spaßig ein uralter Scherz auch ist. Ich finde sowas hat in offiziellen
    > Implementierungen, die eigentlich seriös sein wollen, nichts zu suchen.
    So was hat gerade in offiziellen Implementierungen etwas zu suchen. Das ist ja der einzige Witz daran. Ohne offizielle Implementierung ist das doch total unlustig. Erst dadurch, dass man erwartet, dass solche Implementierungen von bierernsten Bürokraten gemacht worden sind, gewinnt der Fehlercode doch seinen Reiz.

    > Ich hab nichts gegen Scherze, aber bitte nicht in irgendwelchen
    > Spezifikationen! Das macht es für Neulinge doch nur verwirrend und
    > unübersichtlich. Oder soll man wirklich Zeit verschwenden und bei jedem
    > Feature wirklich gucken, ob es ernst gemeint ist. Müssen wir wirklich alle
    > Altlasten aus alten Technikzeiten beibehalten?
    Wieso sollte man damit Zeit verschwenden? Wenn man einen Fehlercode braucht, benutzt man ihn, wenn nicht, dann nicht. Abgesehen, dass das mit dem Teapot offensichtlich ist, stört seine Definition ja nicht, solange man sie nicht verwendet, und sobald man sie verwendet, ist sie nützlich.

    > Das ist zumindest meine Meinung. Wie seht ihr das?
    > Vielleicht bin ich als professioneller Softwareentwickler auch vorbelastet
    > und möchte möglichst sauberen Code haben, der auch gut wartbar bleibt.
    > Manchmal ist das schwerer die Grenze zu erkennen, aber in Code gehört
    > nichts überflüssiges rein.

    Der Code wird ja durch eine zusätzliche Fehlerdefinition nicht schlechter wartbar. Ich halte solche Easter Eggs für eine sehr sehr gute und sinnvolle Maßnahme. Die hat es schon auf dem Amiga gegeben, und ich finde es sehr schade, dass sie in heutigen Betriebssystemen nicht mehr üblich sind.



    1 mal bearbeitet, zuletzt am 13.08.17 15:36 durch janoP.

  5. Re: Begründung falsch?

    Autor: d-tail 2.1 14.08.17 - 06:03

    Mein Gott, es ist EIN EINZIGER Fehlercode. Einer! Wenn's 50 dieser Art wären könnte man ja drüber reden. Google versteckt übrigens auch ständig Easter-Eggs, stören die euch auch?

    d-tail 2.1

  6. Re: Begründung falsch?

    Autor: My1 14.08.17 - 10:08

    d-tail 2.1 schrieb:
    --------------------------------------------------------------------------------
    > Mein Gott, es ist EIN EINZIGER Fehlercode. Einer! Wenn's 50 dieser Art
    > wären könnte man ja drüber reden. Google versteckt übrigens auch ständig
    > Easter-Eggs, stören die euch auch?
    >
    > d-tail 2.1

    erstens das und 2. sind genug frei. und drittens, wenn der jetzt so schlimm wäre sollte man die fehlermeldungen gleich 4stellig oder so machen, dann hat man mehr codes.

    Asperger inside(tm)

  7. Re: Begründung falsch?

    Autor: Gol187 14.08.17 - 11:19

    d-tail 2.1 schrieb:
    --------------------------------------------------------------------------------
    > Google versteckt übrigens auch ständig Easter-Eggs

    Genau:
    https://google.com/teapot

  8. Re: Begründung falsch?

    Autor: mnementh 14.08.17 - 11:31

    Bluejanis schrieb:
    --------------------------------------------------------------------------------
    > Das ist zumindest meine Meinung. Wie seht ihr das?
    > Vielleicht bin ich als professioneller Softwareentwickler auch vorbelastet
    > und möchte möglichst sauberen Code haben, der auch gut wartbar bleibt.
    > Manchmal ist das schwerer die Grenze zu erkennen, aber in Code gehört
    > nichts überflüssiges rein.
    Wenn ich überflüssigen Grafik-Klickibunti-Scheiß weglasse regen sich die Kunden auf. Und das Userinterface ist immer sehr viel aufgeblähter und fehleranfälliger als einfacher Protokoll-Kram wie HTTP.

  9. Re: Begründung falsch?

    Autor: mnementh 14.08.17 - 11:34

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > Dazu noch die Frage, was dieser Status-Code dem Besucher sagen soll, außer
    > dass der Betreiber gerne mit alten Gecks um sich schmeißt, während Besucher
    > auf der Seite etwas sinnvolles erwartet.
    Was? Wer schmeißt denn damit:
    https://upload.wikimedia.org/wikipedia/commons/c/c2/Junger_Stutzer_(15th_century).jpg

    Außerdem dachte ich die Mehrzahl ist Gecken, nicht Gecks. Aber man lernt nie aus.

  10. Re: Begründung falsch?

    Autor: S-Talker 14.08.17 - 11:48

    Bluejanis schrieb:
    --------------------------------------------------------------------------------
    > Soweit ich weiß gibt es bei HTTP-Codes bisher keine Knappheit und es gibt
    > genug freie Codes. Ein Problem sehe ich dort nicht.
    >
    > So spaßig ein uralter Scherz auch ist. Ich finde sowas hat in offiziellen
    > Implementierungen, die eigentlich seriös sein wollen, nichts zu suchen.
    >

    Das ist ein Fehlercode - es besteht keinen Grund und schon keine Verpflichtung diesen zu implementieren es sei denn es tritt genau der use case ein, dass dieser Fehlercode nötig ist.

    > Ich hab nichts gegen Scherze, aber bitte nicht in irgendwelchen
    > Spezifikationen! Das macht es für Neulinge doch nur verwirrend und
    > unübersichtlich. Oder soll man wirklich Zeit verschwenden und bei jedem
    > Feature wirklich gucken, ob es ernst gemeint ist. Müssen wir wirklich alle
    > Altlasten aus alten Technikzeiten beibehalten?
    >

    Wenn du nicht nach einen Teapot Fehlercode suchst, wirst du dieses RFC nie finden und beachten und es hätte keine Konsequenzen. Ein Server der kein Teapot ist wird das sowieso nicht brauchen. Für den Fall dass du Client Entwickler bist und befürchtest, dass jemand deinen Client benutzt, um einen Teapot zu bitten Kaffee zu brühen, selbst dann musst du dich nicht drum kümmern. Ein Client sollte beim Checken eines Fehlers ohnehin am eine einen Default-Zweig haben für "unbekannte Fehler".

    > Das ist zumindest meine Meinung. Wie seht ihr das?
    > Vielleicht bin ich als professioneller Softwareentwickler auch vorbelastet
    > und möchte möglichst sauberen Code haben, der auch gut wartbar bleibt.
    > Manchmal ist das schwerer die Grenze zu erkennen, aber in Code gehört
    > nichts überflüssiges rein.

    Wich bin sehr für sauberen Code. Ein optionaler Scherz stört mich relativ wenig.

    p.s.
    Semi-OT: Firmen, Teams, Umgebungen, in denen man nicht zum Lachen in den Keller geht, sind meiner Erfahrung nach produktiver. Diese klassische Trennung von Spaß/Arbeit mit der Erweiterung einer versuchten Work-Life-Balance etc. ist totaler Humbug.

  11. Re: Begründung falsch?

    Autor: luarix 14.08.17 - 16:10

    Bluejanis schrieb:
    --------------------------------------------------------------------------------
    > Soweit ich weiß gibt es bei HTTP-Codes bisher keine Knappheit und es gibt
    > genug freie Codes. Ein Problem sehe ich dort nicht.
    >
    > So spaßig ein uralter Scherz auch ist. Ich finde sowas hat in offiziellen
    > Implementierungen, die eigentlich seriös sein wollen, nichts zu suchen.

    In alten Dokumenten gerade aus der Netzwerk- oder UNIX-Welt findest Du immer wieder mal irgendwelche Anspielungen, witzige Bemerkungen, etc. Vielleicht hätten die ursprünglichen Autoren ja darauf verzichtet, hätten sie geahnt, dass 30 Jahre später derartige Spassbremsen unterwegs sind. Immer korrekt! Sorry ... aber ist doch wahr -- gibt's keine wichtigeren Dinge über die man sich -- zu Recht -- aufregen kann?

    > Ich hab nichts gegen Scherze, aber bitte nicht in irgendwelchen
    > Spezifikationen! Das macht es für Neulinge doch nur verwirrend und
    > unübersichtlich. Oder soll man wirklich Zeit verschwenden und bei jedem
    > Feature wirklich gucken, ob es ernst gemeint ist. Müssen wir wirklich alle
    > Altlasten aus alten Technikzeiten beibehalten?

    Ach Du Scheisse ... warum traut man Neulingen heutzutage eigentlich so wenig zu? Vor 30 Jahren wurde uns doch auch nicht alles vorgekaut serviert.



    1 mal bearbeitet, zuletzt am 14.08.17 16:11 durch luarix.

  12. Re: Begründung falsch?

    Autor: Hotohori 14.08.17 - 16:57

    Der Witz ist ja, das der TE mit seinem Post eigentlich selbst bewiesen hat warum dieser Code bleiben muss. ;)

  13. Re: Begründung falsch?

    Autor: nikeee13 15.08.17 - 17:22

    janoP schrieb:
    --------------------------------------------------------------------------------
    > So was hat gerade in offiziellen Implementierungen etwas zu suchen. Das ist
    > ja der einzige Witz daran. Ohne offizielle Implementierung ist das doch
    > total unlustig.

    Ja, allerdings in der Referenzimplementierung von HTCPCP, nicht von HTTP (in dessen Spezifikationen 418 nicht festgelegt ist).
    HTTP-"Referenzimplementierungen", die 418 haben, sind deshalb faktisch falsch.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Technische Informationsbibliothek (TIB), Hannover
  2. MULTIVAC Sepp Haggenmüller SE & Co. KG, Wolfertschwenden Raum Memmingen
  3. abilex GmbH, Berlin
  4. Waldorf Frommer Rechtsanwälte, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 6,49€
  2. 219€ (Vergleichspreis 251€)
  3. 19,89€ inkl. Versand (Vergleichspreis ca. 30€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Krankenversicherung: Der Papierkrieg geht weiter
Krankenversicherung
Der Papierkrieg geht weiter

Die Krankenversicherung der Zukunft wird digital und direkt, aber eine tiefgreifende Disruption des Gesundheitswesens à la Amazon wird in Deutschland wohl ausbleiben. Die Beharrungskräfte sind zu groß.
Eine Analyse von Daniel Fallenstein

  1. Imagen Tech KI-System Osteodetect erkennt Knochenbrüche
  2. Medizintechnik Implantat wird per Ultraschall programmiert
  3. Telemedizin Neue Patienten für die Onlinepraxis

Smartphone von Gigaset: Made in Bocholt
Smartphone von Gigaset
Made in Bocholt

Gigaset baut sein Smartphone GS185 in Bocholt - und verpasst dem Gerät trotz kompletter Anlieferung von Teilen aus China das Label "Made in Germany". Der Fokus auf die Region ist aber vorhanden, eine erweiterte Fertigung durchaus eine Option. Wir haben uns das Werk angeschaut.
Ein Bericht von Tobias Költzsch

  1. Bocholt Gigaset baut Smartphone in Deutschland

Battlefield 5 Closed Alpha angespielt: Schneller sterben, länger tot
Battlefield 5 Closed Alpha angespielt
Schneller sterben, länger tot

Das neue Battlefield bekommt ein bisschen was von Fortnite und wird allgemein realistischer und dynamischer. Wir konnten in der Closed Alpha Eindrücke sammeln und erklären die Änderungen.
Von Michael Wieczorek

  1. Battlefield 5 Mehr Reaktionsmöglichkeiten statt schwächerer Munition
  2. Battlefield 5 Closed Alpha startet mit neuen Systemanforderungen
  3. Battlefield 5 Schatzkisten und Systemanforderungen

  1. Quartalsbericht: Aus Microsofts Cloud regnet es Dollar-Milliarden
    Quartalsbericht
    Aus Microsofts Cloud regnet es Dollar-Milliarden

    Das neue Microsoft ist ein höchst erfolgreiches Cloud-Unternehmen. Allein in drei Monaten werden fast neun Milliarden US-Dollar Gewinn erwirtschaftet.

  2. VKU: Forderung nach Gutscheinen zum FTTH-Ausbau wird breiter
    VKU
    Forderung nach Gutscheinen zum FTTH-Ausbau wird breiter

    Drei Verbände schlagen Gutscheine für den Glasfaserausbau vor. Darunter ist auch der Verband kommunaler Unternehmen. Gefördert werden soll der Tiefbau mit 1.500 Euro, auch für Haushalte die keinen Vertag mit Telekombetreibern haben.

  3. Actionspiel: Crytek schaltet Multiplayerserver von Crysis ab
    Actionspiel
    Crytek schaltet Multiplayerserver von Crysis ab

    Nach fast elf Jahren ist Schluss: Crytek will Mitte Oktober die Multiplayerserver von Crysis abschalten. Der Grund: Es gibt nicht mehr genug Spieler für den Actiontitel.


  1. 22:45

  2. 19:19

  3. 16:53

  4. 16:44

  5. 16:41

  6. 16:05

  7. 15:29

  8. 15:18