Diskussion:HTTP-Statuscode

Inoffizielle HTTP Status Codes fehlen

Wie man in der englischen Version dieses Textes sehen kann gibt es Unmengen an inoffizieller Status Codes die unter anderem Cloudflare nutzt, die fehlen komplett und werden nicht erläutert, das fehlt alles. Sebastian Schmidt - 10:39, 11.09.2016 GMT+2 (ohne Benutzername signierter Beitrag von 2A02:8108:8640:1D8:8C6E:CFF:922B:5E61 (Diskussion | Beiträge))

Und was sollten die hier zu suchen haben? Wikipedia ist kein Handbuch für Cloudflare. --93.198.83.233 09:12, 4. Okt. 2017 (CEST)

Spaltenüberschriften

Ich empfehle, Spaltenüberschriften einzuführen. --Regenspaziergang ^!? 18:31, 14. Aug. 2007 (CEST)

Gibt es deutsche Übersetzungen der Meldungen? Falls sie nicht genormt sind, könnte man vielleicht aus irgendeiner Opensource-Applikation die deutschen Meldungen als Beispielübersetzung einfügen.--87.162.23.128 18:01, 25. Nov. 2008 (CET)

Sie sind genormt. --BeanMe (Diskussion) 18:18, 23. Sep. 2012 (CEST)

"kommerzielle" Fehler

Warum gehören kommerzielle Fehler nicht hier her, die im Grunde unique sind (es gibt nur einen Hersteller von Servern mit einem Error-Code 449) und wo fände so etwas stattdessen Platz? Neue, abgegrenzte Tabelle mit diesen Fehlern anlegen? ¸.·´¯`·.¸><((((º> Visie 15:56, 29. Mär. 2009 (CEST)

Ich habe mir gerade HTTP-Fehler 1337 ausgedacht. Warum gehört der nicht hierher? --93.198.83.233 09:14, 4. Okt. 2017 (CEST)

weitere

was betrifft 48 und 815 die sind z.b. nicht erläutert (nicht signierter Beitrag von 79.215.13.90 (Diskussion | Beiträge) 03:31, 27. Jun. 2009 (CEST))

Error 304

Was will uns der Autor damit sagen?

"Die durchgeführte Anfrage führt zur selben Antwort wie zur vom Client übermittelten Zeit im „If-Modified-Since“-Header-Feld oder sie passt zu dem im „If-None-Match“-Header-Feld gesendeten Entity-Tag. Sie wurde deshalb nicht mitübertragen."

Blickt da irgendjemand durch der nicht mal eben sämtliche Header Fields und Entity Tags parat hat und eine schnelle Antwort sucht?

Und so beschreibt es selfhtml (Achtung Copyright!):

"Die angeforderten Daten haben sich seit dem angegebenen Zeitpunkt nicht geändert und werden deshalb nicht gesendet. Dieser Status-Code [...] tritt auf, wenn ein moderner Webbrowser, der die Daten noch im Cache hat, eine Anfrage an den Server sendet und dabei den Ladezeitpunkt der Daten in seinem Cache übermittelt. Stellt der Server dann fest, dass sich die Daten seit dem angegebenen Zeitpunkt nicht geändert haben, braucht er sie nicht noch einmal zu übermitteln, sondern sendet nur diesen Statuscode und keine Daten. Der Browser holt daraufhin seine alte Version aus dem Cache."

Zack! Alles klar, das bedeutet also 304 ... Danke selfhtml, kein Danke Wikipedia -- 93.219.21.7 14:28, 23. Nov. 2009 (CET)

418

Die List ist leider noch nicht vollständig: Der Code 418 nach RFC 2324 fehlt noch.... (nicht signierter Beitrag von 77.25.168.194 (Diskussion | Beiträge) 17:33, 19. Jan. 2010 (CET))

Leider ist das kein HTML-RFC, sondern ein HTCPCP/1.0. Außerdem sagt es selbst It does not specify an Internet standard of any kind. --Steef ³⁸⁹ 18:46, 19. Jan. 2010 (CET)

Guter Witz...

Warum ist dieser Errorcode in der Liste? Er gehört nicht zu HTTP. Ich werde es mal dazu schreiben, da manche Webseiten diesen Code trotzdem in HTTP verwenden. (nicht signierter Beitrag von Nikeee13 (Diskussion | Beiträge) 14:13, 30. Jan. 2012 (CET))

Status Code 449

Die Einleitung erwähnt Status 449 als kommerziellen Status Code erwähnt oder verlinkt diesen aber nicht weiter, der Leser wird im Ungewissen gelassen warum 449 überhaupt erwähnt wird, ich weiß nicht ob MSDN zu verlinken dort angebracht ist (http://msdn.microsoft.com/en-us/library/windows/desktop/aa384325%28v=vs.85%29.aspx), würde aber zu mindestens eine Referenz sein, ansonsten hat eine kurze Recherche ergeben, dass zumindestens Lotus Notes diesen Status Code auch zu verwenden scheint. --2402:1800:4000:1:3158:2BC1:A1B7:6D5C 20:40, 2. Mai 2013 (CEST)

Danke für den Hinweis, und vor allem für die URL.

• Ich muss mal nachdenken, was man mit dem Artikel am besten macht, und wie viele derartiger proprietärer Codes man aufnehmen soll.
• Letzlich können Browser nur die RFC-standardisierten Codes sinnvoll auswerten.
• Was immer in diesem Beispiel von 430 bis 499 zurückkommt, kann letztlich nur von der proprietären Software selbst umgesetzt werden. Mangels Standardisierung kann es auch leicht zu Überschneidungen kommen.
• Ob im Fall der 449 ein Browser The request should be retried after doing the appropriate action. machen kann, oder nur der IE, und was das für eine action sein soll, steht dahin.

Ich denke mal drüber nach; beste Grüße --PerfektesChaos 21:43, 2. Mai 2013 (CEST)

http://blogs.msdn.com/b/exchangedev/ zeigt die Verwendung im Exchange Protokoll auf: Auf 449 soll der Client seinen Policy Key auffrischen und in einem weiteren status_code Feld wird dem Client auch mitgeteilt wieso (zum Beispiel expired). Meines Erachtens sollte man "weitläufige" kommerzielle Status Codes zwar erwähnen aber auf jeden Fall mindestens eine Implementierung verlinken (wie zum Beispiel für 444 bereits getan). Oftmals finden diese HTTP Codes ja eh nur Verwendung in abgeschlossenen Systemen die über HTTP kommunizieren (Wieder Beispiel 444 welches den Browser nie erreicht) und gelangen dann nur teilweise in die öffentliche Verwendung wenn die Protokolle von Drittanwendern adaptiert werden (als Beispiel seien die 403.X Codes vom IIS erwähnt, die nun auch teilweise von anderen Webanwendungen verwendet werden um ihre 403 Responses aufzufächern). Als schönes Beispiel für Überschneidungen sei 420 erwähnt: Twitter sendet es in einer Intention von 429 (https://dev.twitter.com/docs/error-codes-responses), während http://www.w3.org/TR/WD-http-pep-971121 als Teil des Policy Kits aufführt. --2402:1800:4000:1:C1A7:4208:EB98:BF8E 08:50, 3. Mai 2013 (CEST)

Okay, ich versuche mal, das am Wochenende nachvollziehbar abgegrenzt in den Artikel einzuarbeiten und werde die von dir angegebenen präzisen URL dabei verwenden.

Allzu viele der privaten und in abgeschlossener Kommunikation verwendeten Kodierungen werden wir hier allerdings nicht darstellen und pflegen können; aber als kleine Beispielsammlung mag es angehen.

Liebe Grüße --PerfektesChaos 09:35, 3. Mai 2013 (CEST)

Ich habe zu >429 mal ergänzt.

Die Überschneidungen möchte ich nicht erwähnen; das führt auch weit über das Ziel dieser Seite hinaus. Wer so doof ist, einem standardisierten Code eine andere Bedeutung zu geben, muss hier nicht auch noch die Sache verkomplizieren. Anhand der Browser-Kennung und der diversen mitgelieferten Felder kann der Server erkennen, ob es sich um einen Dialog mit der eigenen Anwendung handelt, und dann nach Belieben einen von 70 nicht-RFC zurückschicken; wird die URL nur aus Versehen von einer ungeeigneten Anwendung angefasst, dann ist ein passender standardisierter Code zu senden.

Sonnige Tage --PerfektesChaos 11:35, 5. Mai 2013 (CEST)

Hab mal die beiden Referenzen zusammengeführt. Ich störe mich aber an dem Satz "Die Codes zwischen 430 und 499 sind nicht standardisiert". Da 431 zum Beispiel von RFC 6585 Section 5 als Request Header too large wohl definiert ist. Ich denke eine bessere Forumlierung wäre anzudeuten, dass propertiäre Software die über HTTP kommuniziert oft weitere HTTP Codes definiert mit den dann erwähnten Problemen.

--2402:1800:4000:1:FC81:8132:30FF:FED8 12:54, 7. Mai 2013 (CEST)

Deutsche Fehlermeldung

Benutzer bekommen oft eine Fehlermeldung in deutscher Sprache. Eine zusätzliche Spalte, in der die Fehlermeldung in Deutsch aufgeführt ist, wäre hier also sehr hilfreich. Gruss, --Markus (Diskussion) 08:53, 30. Jun. 2015 (CEST)

Diese "Fehlermeldung" ist z.B. der Inhalt der Seite, den du hier gerade liest. Da kann also alles mögliche stehen. Die englische Bezeichnung hingegen steht so im Standard und ist deshalb in der umseitigen Tabelle enthalten. --nenntmichruhigip (Diskussion) 09:21, 30. Jun. 2015 (CEST)

Entweder habe ich die Antwort nicht verstanden? oder sie passt nicht zu meinem Wunsch, oder mein Wunsch wurde nicht verstanden... (denselben Wunsch gibt es seit 2008). Gruss, --Markus (Diskussion) 23:10, 30. Jun. 2015 (CEST)

Meine Antwort entspricht einem "Nein" auf die obige Frage des accountlosen Benutzers. --nenntmichruhigip (Diskussion) 01:32, 1. Jul. 2015 (CEST)

D.h. die dortige Antwort, dass die Antworten genormt sind, ist falsch? Und es gibt keinen Zusammenhang zwischen den deutschen Antworten und den Statuscodes? Das wäre m.E. unsinnig - wozu gibt es dann deutsche Fehlermeldungen? Und falls es den von mir vermutenten Zusammenhang gibt - dann müsste den doch jemand hier darstellen können? Gruss, --Markus (Diskussion) 07:54, 1. Jul. 2015 (CEST)

Afaik ist die dortige Antwort falsch, ja. Wenn der Benutzer nicht seit 2012 inaktiv wäre hätte ich ihn auch angepingt und nachgefragt was er meinte. Mit "deutsche Fehlermeldung" meinst du doch z.B. so eine Seite (die in diesem Fall mit dem Fehlercode 200 ausgeliefert wird, da sie direkt aufgerufen und gefunden wurde), oder? Das ist einfach das, was als Inhalt ausgeliefert wird. Genauso wie dieser Text der Inhalt einer Antwort mit Fehlercode 200 ist. --nenntmichruhigip (Diskussion) 08:53, 1. Jul. 2015 (CEST)

Info: Die deutschsprachigen Meldungstexte stammen aus dem jeweiligen Browser.

• Es gibt keine internationale Standardisierung dafür.
• Es handelt sich teils um strikte Übersetzungen, teils um freier formulierte Erläuterungen der Fehlersituation nebst Tipps zur Abhilfe und Ursachenanalyse.
• Der Browser sieht den Stauscode 404, 503 oder was immer und kann die vom fremden, fremdsprachlichen Server generierte Standardantwort anzeigen oder aber eine Browser-eigene Seite.
• Auch die standardisierte Nachricht ist nur die unter der Spalte „Nachricht“ aufgelistete Kurzbeschreibung; viele Websites und ihre Software (etwa Apache) generieren eine HTML-Seite mit einer etwas ausführlicheren englischsprachigen Beschreibung.
• Der Browser kann öde HTML-Kurzinfos des Webservers erkennen und nur diese durch eine hübschere und informativere Browser-eigene deutschsprachige Seite ersetzen.

VG --PerfektesChaos 11:55, 3. Jul. 2015 (CEST)

9xx – Proprietäre Statuscodes

Die Tabelle macht überhaupt keinen Sinn. Da es sich um proprietäre Fehler handelt, gibt es keine allgemein gültigen. Und überhaupt ist es nur eine Kopie der "EZproxy-Specific Status Codes", die als Referenz angegeben wurden.

-- Lemmi18 (Diskussion) 14:52, 8. Aug. 2015 (CEST)

Abschnitt gelöscht. --Matthäus Wander 19:34, 8. Aug. 2015 (CEST)

Ich halte den Abschnitt durchaus für sinnvoll, und ich werde ihn demnächst wieder reinsetzen.

Wenn einer unserer Leser auf einen 900er Code trifft und bei uns wissen will, was das ist, hat er ab heute null Information.

Wir schreiben deshalb auf, dass es sowas gibt, dass sie nicht standardisiert sind, und dass die Zahlenwerte keine festgelegte Bedeutung haben.

Ob man diese Beispiel-Zahlenwerte aufführt, ist eine andere Frage; ohne Angabe, welcher Anbieter die absondert, ist die Bedeutungserklärung recht sinnfrei. Zumindest teilweise ist aber ein Beleg vorhanden, und in dessen Kontext ist auch der Zahlenwert okay.

VG --PerfektesChaos 21:29, 8. Aug. 2015 (CEST)

Ok, also der Hinweis, dass Implementierungen nichtstandardisierte Codes verwenden, ist in der Tat sinnvoll. Diesen Hinweis unter 900er Codes zu verorten, ist allerdings nicht sinnvoll, da genauso auch 600er, 700er oder 800er auftauchen können. --Matthäus Wander 01:46, 9. Aug. 2015 (CEST)

• Wir sind nicht dazu verpflichtet, uns nur auf die per RFC/IANA spezifizierten Codes beschränken zu müssen. Das ist ja gerade der Witz an einer Wikipedia, dass man bei uns auch (belegte) Infos bekommt, die woanders nicht so leicht oder überhaupt nicht zu ergoogeln sind. Insofern schlägt bereits die eingangs dieses Diskussionsabschnitts vorgetragene These völlig fehl.
• Unter den 444–451 stehen ja weiterhin einige korrekt gekennzeichnete Beispiele. Es muss halt verdeutlicht sein, dass es sich um proprietäre Codes handelt.
• Die enWP zählt ab 419/420 etliche weitere auf, und markiert jeweils explizit die Hekunft bzw. die fehlende Standardisierung. Das ist völlig okay. Unsere 9xx von en:EZproxy können die auch noch dazukriegen.

VG --PerfektesChaos 10:28, 9. Aug. 2015 (CEST)

"Die Fehlernummern 900 bis 999 sind für private Fehlermeldungen reserviert." - das lese ich hier zum ersten Mal. Mir ist es auch nicht auf Anhieb gelungen, dazu irgendwo anders eine Aussage zu finden. Weiß jemand woher das kommt? Es wäre ja auch denkbar, dass der Nummernkreis nicht offiziell dafür reserviert wurde, aber es sich für proprietäre Codes eingebürgert hat 9xx zu verwenden. --Asarion (Diskussion) 14:48, 6. Dez. 2016 (CET)

„Reserviert“ ist ein starkes Wort, war aber wohl vor drei Jahrzehnten mal informell-halboffiziell so gefallen.

Klar war, dass immer nur die 100er bis 500er offiziell registriert und gruppiert waren, die 600er bis 800er Reserve für unabsehbare Zukünfte sein sollten und mit der 900 für jeden erkannbar war, dass es sich nie um einen offiziellen Code handeln könne, was die Community so „offiziell“ duldete.

Beleg finde ich so von jetzt auf gleich nicht, habe das aber mal irgendwo im letzten Jahrhundert im Rahmen einer konsensualen Diskussion gelesen. Gewohnheitsrecht, würde ich sagen.

In Unicode, in ISO 3166 und ISO 639 usw. finden sich Private-Use-Areas, und eine Analogie war mal vorgesehen, gelangte aber offenkundig nicht in die RFC, und hatte keine praktische Relevanz, weil alles ab 599 per se proprietär sein muss.

VG --PerfektesChaos 15:19, 6. Dez. 2016 (CET)

Verstehe. Wenn wir für diese "Reservierung" keine Quelle haben, schlage ich vor den Satz defensiver zu formulieren und dabei auch Matthäus Wanders Kommentar (01:46, 9. Aug. 2015 (CEST)) zu berücksichtigen. Außerdem wird sowohl in der Einleitung als auch mitten im 4xx-Abschnitt erklärt dass es proprietäre Codes gibt; das sollten wir zentralisieren. Hier mein Vorschlag:

Abschnitt vor "Liste der HTTP-Statuscodes"

Neben den in RFC standardisierten Statuscodes verwenden manche Softwarehersteller auch proprietäre Codes für eigens definierte Status- und Fehlermeldungen. Andere Software kann dem Benutzer diese Codes nur als allgemeinen unbekannten Fehler anzeigen; nicht aber eine Übersetzung und Hinweise zum weiteren Vorgehen. Teilweise können die Server den Begleitumständen der Anfrage bereits entnehmen, dass es sich um die zugehörige Spezialsoftware handelt, und geben nur dann die proprietären Codes zurück. In diesem Artikel sind einige proprietäre Codes aufgeführt und entsprechend gekennzeichnet.

Zwischentext in "4xx – Client-Fehler" (die Zeile mit colspan="3")

Beispiele für proprietäre Codes:

9xx – Proprietäre Fehler

Manche Softwarehersteller verwenden den Bereich ab 900 für proprietäre Statuscodes. Dieser Zahlenbereich findet in den relevanten RFC-Dokumenten allerdings keine Erwähnung und es gibt zahlreiche Beispiele für proprietäre Statuscodes außerhalb dieses Bereichs.

Verbesserungsvorschläge oder Vetos sind willkommen. Wenn ihr nichts dagegen habt, würde ich den Artikel entsprechend ändern.

--Asarion (Diskussion) 23:24, 27. Dez. 2016 (CET)

9xx – Belege fehlen

Ich hab erstmal einen Bapperl reingesetzt. Wenn da in nächster Zeit keine Belege kommen, fliegt der Abschnitt wieder raus. Benutzer:PerfektesChaos, der diesen Abschnitt anscheinend vor längerer Zeit (wieder) reingesetzt hat, hatte nun über ein Jahr Zeit gehabt, Belege zu finden, sei es als proprietäre Codes in aktueller Software oder als Gegenstand historischer Diskussionen. --RokerHRO (Diskussion) 15:13, 1. Mär. 2018 (CET)

Statuscode für "politische Zensur" fehlt

Statuscode für "politische Zensur" Ich kann nicht selber herausfinden, an welcher Stelle ich geblockt werde. Ob mein Überwachungsstaat dies tut oder der Anbieter, den ich aufrufe. auf was hat man sich denn nun geeinigt bei der "politischen Zensur"? 423 oder 523? Diese Fehlercodes erhalte ich immer öfter, wenn ich mich auf ausländischen, politischen Portalen informieren möchte. 84.159.172.223 18:07, 7. Apr. 2017 (CEST)

Also, eine ausdrückliche Kodierung für „Unser Staat übt politische Zensur aus“ gibt es verständlicherweise nicht.

Die 423 (die ja keinerlei Begründung bedarf; könnte auch ein kostenpflichtiges Angebot sein, oder fehlendes Login) bietet sich natürlich an.

Man kann auch rumeiern mit „Service Unavailable“ (503) oder sonstige technische Gründe vorschieben (401, 403).

Oder sich selbst eine proprietäre Kodierung ausdenken. 523 wäre eine.

LG --PerfektesChaos 19:22, 8. Apr. 2017 (CEST)

Status Code 406

Im Text wird der Code 406 missverständlich beschrieben. Man könnte den Text so verstehen, als ob der Code aufgrund eines falschen Content-Type-Headers zurückgegeben wurde. Gemäß RFC basiert die Content-Negotiation aber auf einem der Accept-Header. Ich würde folgenden Text vorschlagen:

Basierend auf denen vom Client gesendeten "Accept"-Headern ist es dem Server nicht möglich, eine Antwort im entsprechenden Format zu produzieren. Der Server kann bei seiner Antwort eine Liste der zur Verfügung stehenden Antwortformate mitliefern, ist dazu aber nicht verpflichtet.

--Dploeger (Diskussion) 15:22, 1. Sep. 2017 (CEST)

Naja, falsch verständlich ist das momentan eigentlich nicht, höchstens schwer verständlich.

Ich würde die knappe, übersichtliche Formulierung gern belassen, eher erweitern:

Die angeforderte Ressource steht nicht in der gewünschten (Accept-)Form zur Verfügung. Gültige „Content-Type“-Werte können in der Antwort übermittelt werden.

„Werte können in der Antwort übermittelt werden“ sagt bereits alles aus; mehr liefert auch nicht: „Der Server kann bei seiner Antwort eine Liste der zur Verfügung stehenden Antwortformate mitliefern, ist dazu aber nicht verpflichtet.“

LG --PerfektesChaos 15:35, 1. Sep. 2017 (CEST)

"426 Upgrade Required" ist hier falsch erklärt.

"Der Client sollte auf Transport Layer Security (TLS/1.0) umschalten" stimmt nicht. Der verlinkte RFC ist nur ein Beispiel für die Benutzung von 426. Der richtige RFC ist https://tools.ietf.org/html/rfc7231#section-6.5.15 - dort steht auch als Beispiel "This service requires use of the HTTP/3.0 protocol". --84.182.231.214 08:59, 18. Dez. 2017 (CET)

Danke, ist geändert. --Matthäus Wander 15:08, 1. Jan. 2018 (CET)

Requested range not satisfiable

Requested range not satisfiable ist oft auch ein Zeichen dafür, dass der Server den geforderten Abschnitt der Datei evtl. bereitstellen würde - aber generell nur ganze Dateien versendet und nicht die Anfrage nur einer Range daraus unterstützt -Peterpall (Diskussion) 07:45, 21. Mär. 2018 (CET)

Error 523

Den gibt es zum Beispiel bei der Adresse von hier => Error 523. Auch im Internet gibt es Hinweise darauf. Ist der neu? Ich find in den rfcs keinen Hinweis. Gruss --Nightflyer (Diskussion) 00:22, 16. Apr. 2018 (CEST)

Es handelt sich um einen „proprietären“ Code; also um einen, den Cloudflare sich selbst für eigene Zwecke ausgedacht hat.

• Deshalb steht er auch in keinem RFC.
• Geeignete Software könntte ihn verstehen; die 500er signalisieren, dass es sich um ein Problem der Netzwerkkommunikation mit dem Server handelt.

Aus deiner Google-URL habe ich Infos rausgelöscht, die einen Rückschluss auf deine ursprüngiche Abfrage dort ermöglichen.

LG --PerfektesChaos 11:55, 16. Apr. 2018 (CEST)

Warum wird "499 - Client Closed Request" erwähnt? Ist der nicht komplett sinnfrei?

Der Server merkt, dass der Client weg ist und teilt dem Client selbiges mit?! Das Zeug, was der Erfinder dieses Status geraucht hat, möchte ich auch mal probieren. :) --93.227.5.106 14:35, 31. Jul. 2018 (CEST)

Soweit ich weiß wird der Statuscode in den Logdateien verwendet. FullEdit (Diskussion) 10:27, 6. Dez. 2018 (CET)

Ich habe eben einen 499 als Antwort in meinem Browser erhalten !?!?!?

In anderen Sprachen (Site Links)

Diese Seite ist Teil von https://www.wikidata.org/wiki/Q19862850

In https://www.wikidata.org/wiki/Q1123288 sind aber viel mehr Seiten miteinander verlinkt. (Dort ist https://de.wikipedia.org/w/index.php?title=Liste_der_HTTP-Statuscodes&redirect=no hinterlegt.)

Daher kommt man von en nach de, aber nicht von de nach en.

Wie kann man Q19862850 in Q1123288 integrieren? (nicht signierter Beitrag von Voomdoon (Diskussion | Beiträge) 17:11, 1. Apr. 2021 (CEST))

Heute kommt man von DE nach EN aber nicht EN nach DE.

https://de.wikipedia.org/wiki/Wikipedia:Projektdiskussion --Fanta AG (Diskussion) 19:48, 25. Aug. 2023 (CEST)