Diskussion:Hypertext Transfer Protocol/Archiv1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Hypertext Transfer Protocol/Archiv1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Hypertext_Transfer_Protocol/Archiv1#Thema_1

HTTP Methoden

Ich habe die PUT und DELETE Methoden ein wenig ergänzt um auf die RESTfull Services zu verweisen die immer mehr Verbreitung finden. Grund: ich wollte über HTTP auf Artikel kommen um mich in REST einzulesen, war aber nicht möglich das zu machen da es keinen einzigen Link dazu gibt auf der Seite. Falls die Formulierung nicht passt bitte ändern, ich bin nicht unbedingt erfahren in diesen Dingen, denke aber das die Information auf alle Fälle verlinkt sein sollteAutor Unbekannt 00:00, 1. Jan. 2008 (CST)

Schicht 7 = Anwendungsschicht

Der Artikel ist fehlerhaft bzw. irreführend: "Auch ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht, zum Beispiel durch Cookies, implementiert werden." HTTP arbeitet ja auf der Anwendungsschicht. Autor Unbekannt 00:00, 1. Jan. 2008 (CST)

OSI/ISO Schichtenmodel

Es gibt eine eigene Seite für die Erklärung des Schichten-/Refenezmodels, deshalb sollte hier die etwas umständliche Erklärung raus! Und einfach der Hinweis auf die entsprechende Schicht genügenAutor Unbekannt 00:00, 1. Jan. 2008 (CST)

Beispieldomains

Als Beispieldomains sollte nur .example.net, .example.org etc. verwendet werden.Autor Unbekannt 00:00, 1. Jan. 2008 (CST)

Statuscodes

Ist es wirklich sinnvoll die Statuscodes in den Artikel mit einzubinden ? Ein Verweis auf rfc-editor.org ist da meiner Ansicht nach angebrachter. -- Mijobe 15:46, 29. Mär. 2004 (CEST)

Ruhig Redundanz

Ich denke, dass die Statuscodes nicht schaden und es geht ja um schnelle Informationsbereitstellung. Wenn ich mir die Infos erst durch Klicken zusammensuchen muss, kostet das Zeit (und manchmal auch Nerven). Klar, vom informationstheoretischen Ansatz her ist die Referenzloesung das A&O aber von der Praxis her ist es so besser.

--- Nö, finde ich nicht. Ich finde, die Statuscodes stellen hier einen gewissen Information-Overkill dar: Um zu verstehen, wie HTTP funktioniert, muß man nicht alle Statuscodes kennen. Und wenn schon, dann muß jeder Code auch erklärt werden. Der englische Bezeichner reicht IMHO nicht aus. Außerdem: Wikipädia ist auch mehr ein Lexikon als ein Referenzwerk. Der Verweis auf die RFC reicht also. -- alex

Ich halte die Auflistung der Statuscodes hier auch für vollkommen fehl am Platze und möchte sie gerne entfernen. -- molily 20:28, 12. Jun 2005 (CEST)

Ich denke ein Kompromiss wäre sinnvoll: Die Rolle der Statuscodes sollte erklärt werden zusammen mit den diversen Klassen (1xx für Zwischenmeldungen, 2xx für positive Antworten, 3xx für Umleitungen, 4xx für Clientfehler und 5xx für Serverfehler). Außerdem sollten einige wichtige Statuscodes wie 200, 301, 302, 403, 404 kurz exemplarisch beschrieben werden. Gerade 404 und 403 bekommen ja selbst normale Benutzer gelegentlich zu sehen. --X4u 15:58, 4. Sep 2005 (CEST)

Halte ich für ne gute Idee!!! Chri.koch 19:23, 4. Sep. 2005 (CEST)

Erklärung der Code-Typen und ausgesuchter, öfters gesehener Codes erscheint auch mir sinnvoller als die komplette Liste --Schoschi 13:36, 18. Mär 2006 (CET)

Ich halte es für am Besten, die Statuscodes auf eine andere Seite (z.B. HTTP-Statuscodes) auszulagern, eine Kurzübersicht (1xx, 2xx etc.) kann ja hier bleiben. marian.sigler 14:30, 14. Apr 2006 (CEST)

Das hab ich jetzt mal gemacht. --MarianSigler {bla} {+-} 22:00, 26. Jun 2006 (CEST)

Ich würde die Statuscode lieber im Artikel lassen, da sie nun mal (alle) zu HTTP gehören und ein wichtiger Bestandteil davon sind. Vielleicht könnte man aber die Authentifizierung nach oben nehmen, damit sie Statuscodes am Schluss stehen und nicht stören. -- net 17:50, 14. Apr. 2006 (CEST)

TCP stellt zur Verfügung?

Der Satz "Es ist eines der Protokolle, die der TCP/IP-Protokollstapel bereitstellt." scheint mir irreführend zu sein. HTTP wird über TCP/IP realisiert - jedoch impliziert TCP/IP kein HTTP... Evtl. könnte der Satz "HTTP ist ein Anwendungsprotokoll, das über das TCP Protokoll realisiert wird." besser sein. Allerdings klingt der ziemlich hölzern.

--- Finde ich auch! Der Satz gehört weg. An dieser Stelle reicht vielleicht ein Hinweis, daß es sich um ein Protokoll auf Layer 7 handelt - mit Verweis auf das ISO-OSI-Modell. -- alex

--- Stimm ich absolut zu! Dass TCP das Protokoll HTTP "zur Verfügung stellt", ist einfach falsch! Es wird zwar in 99,99999% der Fälle über TCP genutzt. Theoretisch ließe sich ja aber auch ein anderes Transportprotokoll nutzen. Chri.koch 19:14, 17. Jun. 2005 (CEST)

Ist das noch aktuell? Ich kann die Passage nicht finden, bitte schaut nochmal, ggf diesen teil der Diskussion löschen. --Schoschi 13:40, 18. Mär. 2006 (CET)

Daten Encoding von Sonderzeichen

Irgendwie fehlt mir in dem Artikel eine Erklaerung oder Link zum Encoden von uebertragenen Daten, wenn diese nicht US-ASCII sind. Also die Wandlung von z.B. Umlauten in die %XY Darstellung. Dies wird sicher immer mal jemandem aufgefallen sein, ohne das er weiss, was es damit auf sich hat. Dies aber eventuell als Link auf einen anderen Text, da das Encoding nicht die HTTP-Kommunikation selbst veraendert, aber dennoch ein wichtiger Bestandteil der Datenuebertragung ist. 217.17.202.254 09:16, 25. Apr 2006 (CEST)

HTTP Erklaerung allgemein

Es wird in der Einleitung einmal auf ein zustandsloses Protokoll eingegangen. Kurz danach wird wieder auf Sitzungsdaten verwiesen. Diese wollten einen Verweis auf den Artikel Sitzung (Informatik) erhalten. Damit wird wohl den meisten erst klar, was an dieser Stelle gemeint ist.

Und irgendwie sollte nochmal explizit rein, dass es sich um ein Protokoll handelt, welches zu einem Request genau einen Response liefert. Wenn in einer Webseite also mehrere Bilder enthalten sind, so muessen dann auch mehrere Requests an den Server gesendet werden. 217.17.202.254 09:16, 25. Apr. 2006 (CEST)

HTTP/2.0 od. HTTP/NG

bin grad auf eine seite gestoßen und ich frag mich, ob da etwas dran ist an dieser version 2.0. für mich klingt das eher nach einem gerücht, aber vielleicht weiss ja jemand näheres darüber. http://java.fh-wolfenbuettel.de/Seminare/www/HTTP/ --Pythagoras1 16:09, 14. Jan 2006 (CET)

Na ja, die von dir zitierte Seite stammt vom 24. Januar 1996 und sagt uns HTTP/2.0 bzw. HTTP/NG für Dezember 1996 vorher. Das war wohl ein bisschen voreilig, die Arbeitsgruppe hat Ende 1996 ihre Vorschläge präsentiert und ist dann sanft entschlafen; es ist nicht geplant, an HTTP-NG weiterzuarbeiten. (Siehe [1]: The HTTP-NG Activity produced a number of proposals [...], which were presented to W3C members and at an IETF meeting in Dec. 98. At the moment, W3C does not plan any follow-up work on HTTP-NG.). -- Stefan506 16:20, 14. Jan. 2006 (CET)

Abgeschlossene Lesenswertdiskussion (gescheitert)

Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem World Wide Web (WWW) in einen Webbrowser zu laden.

• pro - und ein weiterer Artikel aus diesem Themenfeld um das Trio komplett zu machen. -- Achim Raschka 15:37, 24. Mär 2006 (CET)
• Pro, aber ich habe gerade noch zwei Sätze in der Einleitung ergänzt, die, wie ich fand, fehlen ("Datenübertragung in Netzwerken ist ein komplexes Problem". Ja? Warum?) Sollte ich das zu ungenau beschrieben haben (glaube aber nicht), einfach nochmal ändern. --Vierte Welle 14:53, 26. Mär. 2006 (CEST)

• Contra - Es wird leider nicht erklärt was ein Request eigentlich ist. Vor der langen Liste mit den Statuscodes, bei denen man sich auch fragt, ob man das nicht auslagern sollte, wäre eine Erkärung gut, wozu man diese Codes überhaupt benötigt. Manche Begriffe wie Header, Netzwerk, Schichtenmodell usw. sind erst beim zweiten oder dritten Auftreten im Text verlinkt. Andere wie Server, Chat oder Feature sind gar nicht verlinkt. Oder sind das keine Fachbegriffe ? Die Authentifizierung wird in vier Zeilen "abgespult". Literatur gibt es zu dem Thema anscheinend gar nicht. Seltsam. Gruß Boris Fernbacher 11:59, 27. Mär 2006 (CEST)

• sehr knappes  Kontra, wie der Boris ueber mir: Einleitung ist jetzt zu lang und unverlinkt (Schon Netzwerk (gemeint ist meiner Meinung ein Computer-Netzwerk) und Daten sind nicht trivial genug, dass ein Link unterbleiben duerfte. Es fehlt eine Erklaerung, was der Unterschied zwischen Daten und Information ist, obwohl ihre Trennung als Kernproblem der Protokolle genannt wird (Link ist weder auf ein Lemma zum Unterschied, noch zu Daten oder Information gesetzt). Zwar ist Fachsprache bei den Lesenswerten noch erlaubt, aber so ist es mir knapp nicht lesenswert, mit etwas Feinschliff waere dieser Zustand aber schnell zu erreichen.--Syrcro.ПЕДИЯ^® 09:18, 31. Mär. 2006 (CEST)

Linkproblem bei Argumentübertragung mit GET

Mit der Änderung http://de.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&diff=prev&oldid=33028802 ist ein Link unklickbar geworden. Der Ändernde hat sich sicher was dabei gedacht, ich weiss bloß nicht was.

Hallo Unbekannter Nr.1, es fehlte einfach nur ein Abschnitt für die Referenzen, den ich jetzt eingefügt habe. -- net 16:58, 17. Jun. 2007 (CEST)

Copyright

In den Medien taucht u.a. http als Beispiel für nicht offene Standards auf [2]. Der Wikipedia-Artikel bietet dazu keine Hinweise? --Sputnik 15:07, 4. Jul. 2008 (CEST)

Argumentübertragung und Beispiel GET

Ich habe den Passus über URL Encoding erweitert/verschärft, und daran anschließend URI durch URL ersetzt: an dieser Stelle sind m.E. keine URNs (z.B. urn:iso:tech:iso20222) erlaubt. Gfis 19:55, 20. Jul. 2008 (CEST)

Ich habe mal im passenden RFC nachgeschaut und da steht leider URI als GET-Parameter. Danach wird nur die Resource als URL beschrieben, wo dann auch das Protokoll drin steht. Aber die Bedeutung von URL und URI haben sich in den Jahren ja etwas geändert. Insofern finde ich eine Entscheidung schwierig und würde deshalb eher zum RFC-Begriff URI tendieren. Das einzige was mir einfällt ist, dass es auch Erweiterungen zu HTTP gibt, die z.B. eine Lampe ein/ausschalten. Dann steht da eine URI, die weder eine URL, noch eine URN ist.--Merlissimo 23:03, 20. Jul. 2008 (CEST)

Authentifizierung

Benutzer:Alauda hat die Bezeichnung von Basic Authentication als häufigste Form der Authentifizierung enfernt mit der Begründung "Ich kenne kaum große Seiten, die diese Authentifizierung verwenden. Von "häufigste" zu sprechen ist übertrieben." Es stimmt natürlich, dass vor allem kleine Webseiten Basic Authentication verwenden. Allerdings sind die Anmeldeverfahren auf großen Seiten gar keine in HTTP definierten Verfahren, sodass Basic Authentication immer noch die häufigste HTTP-eigene Variante ist. --Joha.ma 23:13, 18. Jun. 2007 (CEST)

Sehr gute Begründung, die mich absolut überzeugt. Alauda 21:24, 20. Jun. 2007 (CEST)

Habe das häufig mal ein bischen relativiert und erwähnt, dass große Webauftritte andere Verfahren einsetzen.--Joha.ma 22:26, 25. Jun. 2007 (CEST)

Der Abschnitt Authentifizierung ist etwas mager. Da koennte erstmal ein Link auf den Artikel zur Authentifizierung rein, damit auch das nochmal naeher erklaert wird. Weiterhin koennte zu den verschiedenen Methoden nochmal eine gewisse Erklaerung zur Funktionsweise und zur Sicherheit rein. Aktuell ist es ja mehr eine Linksammlung auf RFCs. 217.17.202.254 09:16, 25. Apr 2006 (CEST)

Gast meint: "da sich die Eingabefelder für Benutzername und Passwort nur mit Javascript in die Webseite einbetten lassen." Nach meinem Kentnisstand ist das absoluter quatsch. Wie zwei Sätze weiter oben ja steht: "meldet er das dem Browser mit dem Statuscode 401 Unauthorized und dem Header WWW-Authenticate". Nun ist es alleine Sache des Browsers ein Loginprompt anzuzeigen. Diesen einzubetten würde sich relativ schwer gestalten.

Hier ist beschrieben, wie man mit JavaScript den Prompt umgeht. Alauda 21:23, 15. Sep. 2008 (CEST)

Das ist aber eher ein Hack als eine standarisierte Vorgehensweise --Benji 22:09, 15. Sep. 2008 (CEST)

Erweiterung der HTTP Post sektion

Könnten wir die HTTP Post-Sektion um File Uploads erweitern. Das im allgemeinen Sprachgebrauch gebräuchliche posten von Bildern und anderen Medien, hätte hier wohl am Sinnvollsten aufgehoben. Ich hätte mir einen Upload eines kleinen unbedenklichen Bildes auf den Wikipedia-Server vorgestellt, derzeit wird nur eine Suchabfrage illustriert. Im HTTP 1.1 Standard hatte ich forgendes Beispiel gefunden.

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Ist ein solches Beispiel hier erwünscht oder sollte ich besser den Hochladen-Artikel erweitern? --Yamavu 10:32, 1. Dez. 2008 (CET)

SSL und GET

Grundsätzlich können Daten auch mittels GET übertragen werden (als Argumente im URI), aber die Übertragung der Argumente erfolgt bei POST diskret (wichtig bei sensiblen Daten), und die zulässige Datenmenge ist deutlich größer.

Wenn ich das SSL RFC richtig verstanden habe, werden auch die URL Parameter nicht im Klartext uebetragen, sondern erst nach dem Aufbau der SSL Verbindung kodiert. Habe ich da etwas falsch verstanden? Traute Meyer 21:38, 17. Jan. 2009 (CET)

URLs inkl. Parameter mit evtl. sensiblen Daten können bei GET aber im Browser-Verlauf und -Cache landen oder in Logfiles auf dem Webserver oder Proxies gespeichert werden. Das ist damit gemeint. -- net 21:46, 17. Jan. 2009 (CET)

Danke, Du hast mich da auf etwas wichtiges hingewiesen (Browser-Verlauf). Das hatte ich bis dato nicht einbezogen. Traute Meyer 00:42, 23. Jan. 2009 (CET)

Protokollversionen

Bei HTTP gehen Informationen aus früheren Anforderungen verloren (zustandsloses Protokoll). Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können. [...]

Hat das wirklich was mit der Protokollversion zu tun? Und wenn, dann sollte man doch schreiben auf welche Protokollversion das zutrifft. --195.3.81.41 15:48, 16. Apr. 2009 (CEST)

Beispiel im Artikel

Das Beispiel mit den Parametern (Katzen) und wahrscheinlich auch das einfachere (Habe ich nicht geprüft), geben nicht das zurück, was im Artikel steht, sondern "Please provide a user-agent header". IMHO sollte man das Beispiel entsprechend anpassen (header mitsenden) oder ein anderes Beispiel (anderer host) wählen, wo der user agent nicht gefordert ist.

-my two cents --212.101.17.63 11:47, 28. Okt. 2009 (CET)

Geschichts-Notiz

12 Lines Teletype- Modell (US) als Urprung (Referenzen?) könnte beleuchtet werden; demnach müsste es Hyper-Terminal-Transfer-Point heißen - Protokoll auf anderer Ebene.

Quelle: retired US SSG

--L1nk. (nicht signierter Beitrag von 78.94.58.104 (Diskussion | Beiträge) 20:15, 28. Okt. 2009 (CET))

einleitung

gudn tach!
zu [3]: grundsaetzlich begruesse ich die bestrebung die hiesige einleitung zu kuerzen. dabei sollte allerdings darauf geachtet werden, dass sie fuer leser auch halbwegs verstaendlich ist, ohne dass man alle querverweise abklappern muss. "Protokoll zur Übertragung von Daten über ein Netzwerk" ist wesentlich verstaendlicher als "zustandsloses Client-Server Protokoll in der Anwendungsschicht", auch wenn das zweite fachlich praeziser waere.
da ausserdem ein satz versehentlich verstuemmelt wurde, revertierte ich mal den edit, weil ich unschluessig war, wie man das reparieren sollte. -- seth 09:35, 3. Jan. 2010 (CET)

Meines Erachtens hat eine Beschreibung von HTTP in dieser Form hier nichts zu suchen - ein Querverweis (wie er schon existiert) ist völlig ausreichend ... ml 11:35, 6. Sep. 2010 (CET)

Ich würde eine Anderung auf "zustandsloses Client-Server Protokoll in der Anwendungsschicht" begrüßen, aktuell ist die Einleitung fernab von technischer Verständlichkeit. --suit 12:15, 6. Sep. 2010 (CEST)

POST

Wahrscheinlich sollte es statt

HTTP-POST: Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart in den HTTP-Kopfdaten, so dass sie in der URL nicht sichtbar sind.

heißen:

HTTP-POST: Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart im HTTP-Body, so dass sie in der URL nicht sichtbar sind.

Außerdem: Warum darf man den Artikel nicht direkt korrigieren? (nicht signierter Beitrag von 134.155.149.38 (Diskussion) 01:20, 16. Jan. 2011 (CET))

gudn tach!

ja, "kopfdaten" ist auch meiner meinung nach falsch. ich aendere es mal.

der artikel ist derzeit fuer unangemeldete user gesperrt, da in der vergangenheit fast alle edits von unangemeldeten usern revertiert wurden, siehe [4]. -- seth 12:19, 16. Jan. 2011 (CET)

Dieser Abschnitt ist doch sowieso doppelt, da die Argumenteübertragung schon im vorherigen Absatz erklärt wurden. Außerdem werden auch bspw. bei PUT und DELETE Argumente übertragen, was dann natürlich auch noch mal erklärt werden müsste. Ich würde den Abschnitt daher komplett löschen. --net 16:53, 16. Jan. 2011 (CET)

gudn tach!

was genau wuerdest du loeschen? die beispiele auch? oder nur die einleitung des abschnitts "Argumentübertragung"? beispiele sind hier imho schon eine verbesserung der rein theoretischen erklaerung. -- seth 18:03, 16. Jan. 2011 (CET)

Persistenz

Unter Protokollversionen steht:

"Bei HTTP/1.1 kann ein Client durch einen zusätzlichen Headereintrag (Keep-Alive) den Wunsch äußern, keinen Verbindungsabbau durchzuführen, um die Verbindung erneut nutzen zu können (persistent connection). Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxies Probleme bereiten."

Das stimmt so nicht. Siehe dazu auch http://tools.ietf.org/html/rfc2616#section-19.6.2. Persistente Verbindungen sind das Standardverhalten.

SPDY

Hi, vermutlich ist SPDY eines eigenen Artikels würdig. Trotzdem wäre doch ein Hinweis an dieser Stelle auch gut, dass es SPDY als HTTP-Erweiterung bzw. Prinzipabänderung gibt, oder? MfG --94.223.118.196 14:16, 25. Mai 2013 (CEST)

Service: SPDY. --46.115.87.158 11:27, 27. Mai 2013 (CEST)

ISO/OSI-Referenzmodell

Hallo, im Artikel steht in der Einleitung, zweiter Absatz, dass das HTTP ein Protokoll der Anwendungsschicht ist. Das ist soweit richtig. Allerdings wird hier auf das ISO/OSI-Referenzmodell Bezug genommen und darauf hingewiesen, die Anwendungsschicht sei auf den Schichten 5-7. Das ist nicht richtig. Im ISO/OSI-Referenzmodell ist die Anwendungsschicht in der 7. Schicht anzusiedeln. Würde sich deine Aussage auf das TCP/IP-Modell beziehen, wäre deine Aussage richtig. (nicht signierter Beitrag von 91.5.22.40 (Diskussion) 01:24, 7. Feb. 2014 (CET))

"Aufgaben wie die Datenkompression und die Verschlüsselung gehören zur Schicht 6": Was ist mit HTTPS und HTTP-Kompression? Schicht 5 – Sitzungsschicht: Was ist mit Cookies?--Kulandru mor (Diskussion) 12:22, 4. Nov. 2014 (CET)

infographiken

Auf wikimedia commons sind 2 infographiken entstanden, die beide den artikel erweitern koennten, meiner meinung nach jedoch nicht 100% passen. Daher wollte ich die meinung von erfahreneren Wikipediaautoren haben File:PosterDSA_-_Technischer_Ablauf_beim_Aufruf_einer_Website.svg und File:HyperTextTransferProtocol.svg ob diese graphiken im HTTP oder einem aehnlichen Artikel eingebunden werden sollten. --Renepick (Diskussion) 00:21, 13. Jul. 2015 (CEST)

HTTP2.0

Zur neuen Version fehlt meiner Meinung nach noch ein Kritikabschnitt, z.B. dass eine "binär kodierte Übertragung von Inhalten", das einfache Abhören sehr erschweren dürfte und damit die Kosten für die Gemeinschaft erhöhten könnte und wie man diese Problematik in Zukunft regeln möchte...--46.114.9.117 13:42, 22. Okt. 2015 (CEST)

Wie hoch die Kosten für die Gemeinschaft nur geworden wäre, wenn HTTP/2 eine obligatorische Verschlüsselung vorgesehen hätte. Eventuell sollten wir eine solche Kritik auch bei Firefox und Google Chrome ergänzen, die sich einfach weigern nicht-verschlüsseltes HTTP/2 zu unterstützen, nachdem zum Gemeinwohl gerade noch in letzter Sekunde eine entsprechende Verpflichtung aus dem Standard gestrichen werden konnte. --Häuslebauer (Diskussion) 14:40, 22. Okt. 2015 (CEST)

"Binär kodierte Übertragung von Inhalten" ging doch auch schon mit HTTP 1.0, oder wie erhaltet ihr eure Bilder, Texte und HTTP-komprimierte Inhalte? --nenntmichruhigip (Diskussion) 16:00, 22. Okt. 2015 (CEST)

"DELETE ... kaum implementiert beziehungsweise in der Standardkonfiguration von Webservern abgeschaltet"

Dafür hätte ich gern mal 'ne seriöse Quelle. Wie (und warum?!) soll man das abschalten können? Nur weil einige "php-Profis" nix anderes als POST und GET kennen, heißt das noch lange nicht, dass die anderen Methoden "ungewöhnlich" wären. --80.153.250.36 09:59, 5. Sep. 2016 (CEST)

Stammt offensichtlich aus einer Zeit vor der Verbreitung von RESTful Services. PATCH Methode fehlt auch. --Häuslebauer (Diskussion) 10:05, 5. Sep. 2016 (CEST)

PATCH "noch nicht verabschiedet"?

PATCH

Ändert ein bestehendes Dokument ohne dieses wie bei PUT vollständig zu ersetzen. Wurde erst später durch RFC 5789 als Erweiterung des Standard vorgeschlagen (noch nicht verabschiedet).

Das "noch nicht verabschiedet" halte ich für grob irreführend. Zwar ist laut der offiziellen Liste der RFC 5789 ein sogenannter "Proposed Standard", aber dasselbe gilt nunmal auch für sämtliche anderen RFCs zu HTTP selbst sowie zu WebDAV, und das ist völlig normal. Kurzum: PATCH ist vieleicht nicht so verbreitet wie andere HTTP-Methoden, aber formal genauso standardisiert wie die anderen.
Wenn also niemand einen Grund nennt, warum "noch nicht verabschiedet" beibehalten werden soll, entferne ich es. --Asarion (Diskussion) 07:49, 25. Feb. 2018 (CET)

Erledigt. Habe darüber hinaus auch das "wurde erst später" entfernt, da es meines Erachtens abwertend klingt und auch bei Methoden wie CONNECT nicht auftaucht. --Asarion (Diskussion) 10:14, 3. Mär. 2018 (CET)

Länge des URIs bei GET

Im Abschnitt HTTP-Anfragemethoden steht unter GET: „Die Länge des URIs ist je nach eingesetztem Server begrenzt und sollte aus Gründen der Abwärtskompatibilität nicht länger als 255 Bytes sein.“ Gibt es für diese Aussage eine Quelle? In RFC 2616 steht zwar: „Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.“ Aber erstens wäre diese Aussage (falls das denn die Quelle sein soll) hier falsch wiedergegeben, zweitens ist RFC 2616 obsolet und zumindest ich habe eine ähnliche Aussage in RFCs 7230–7235 nicht gefunden und drittens ist eine Grenze von 255 Zeichen sicher nicht praxisrelevant. Natürlich haben alle real existierenden Implementierungen irgendwo eine Längenbegrenzung, die liegt in der Praxis aber eher irgendwo zwischen 4000 und 8000 Zeichen, teilweise noch deutlich darüber, siehe [5], [6], [7].

Sollte sich keine Quelle für ein Limit in den RFCs finden, schlage ich vor, den Satz ersatzlos zu streichen. --134.30.210.106 10:26, 24. Jul. 2019 (CEST)

Da niemand meiner Einschätzung widersprochen hat und auch keine Quelle für diese Aussage genannt wurde, habe ich diesen Satz jetzt gelöscht. --134.30.210.106 14:15, 27. Sep. 2019 (CEST)

Digest Access Authentication

Sollte hier nicht die Rede statt von einer Verschlüsselung eher von einer Kryptographischen Hashfunktion sein? Mir wäre noch nie eine Hash-Funktion, die verschlüsselt, untergekommen. Will das an dieser Stelle aber zuerst diskutieren, bevor ich oder jemand anderes das ändert. Ich meine, in diesem Abschnitt wird v.a. für den Unbedarften Leser eine falsche Vorstellung von einer Hash-Funktion vermittelt. --Tufta (Diskussion) 08:27, 23. Sep. 2020 (CEST)

Bin dem nun im verlinkten weiterführenden Artikel HTTP-Authentifizierung nachgegangen, und dort ist es korrekt beschrieben. Habe nun den Artikel ohne weitere Diksussion hier angepasst. --Tufta (Diskussion) 07:14, 28. Sep. 2020 (CEST)

Bemerkenswerterweise wurde die Änderung ohne Diskussion rückgängig gemacht, obwohl eine Hashfunktion wie auch im verlinkten Artikel korrekt beschrieben nicht verschlüsselt. Was spricht dagegen, dies hier sachlich korrekt wiederzugeben.?--Tufta (Diskussion) 14:20, 18. Jan. 2021 (CET)