Diskussion:Hypertext Transfer Protocol/Archiv1

message: 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)
thread_title:  HTTP Methoden 

message: 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)
thread_title:  Schicht 7 = Anwendungsschicht 

message: 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)
thread_title:  OSI/ISO Schichtenmodel 

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

message: 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)
thread_title:  Statuscodes 

message: 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)
replies: text: 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)
replies: text: Halte ich für ne gute Idee!!! Chri.koch 19:23, 4. Sep. 2005 (CEST)

text: 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)

text: 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)
replies: text:  Das hab ich jetzt mal gemacht. --MarianSigler {bla} {+-} 22:00, 26. Jun 2006 (CEST)
thread_title:  Ruhig Redundanz 

message: 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)
replies: text: 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)
thread_title:  TCP stellt zur Verfügung? 

message: 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)
thread_title:  Daten Encoding von Sonderzeichen 

message: 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)
thread_title:  HTTP Erklaerung allgemein 

message: 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)
replies: text: 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 : 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)
thread_title:  HTTP/2.0 od. HTTP/NG 

message: 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)
thread_title:  Abgeschlossene Lesenswertdiskussion (gescheitert) 

message: 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)
thread_title:  Linkproblem bei Argumentübertragung mit GET 

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

message: 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)
replies: text: 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)
thread_title:  Argumentübertragung und Beispiel GET 

message: 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)
replies: text: Sehr gute Begründung, die mich absolut überzeugt. Alauda 21:24, 20. Jun. 2007 (CEST)
replies: text: 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)

text: Hier ist beschrieben, wie man mit JavaScript den Prompt umgeht. Alauda 21:23, 15. Sep. 2008 (CEST)
replies: text: Das ist aber eher ein Hack als eine standarisierte Vorgehensweise --Benji 22:09, 15. Sep. 2008 (CEST)
thread_title:  Authentifizierung 

message: 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)
thread_title:  Erweiterung der HTTP Post sektion 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  SSL und GET 

message: 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)
thread_title:  Protokollversionen 

message: 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)
thread_title:  Beispiel im Artikel 

message: 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)
thread_title:  Geschichts-Notiz 

message: gudn tach!
zu : 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)
replies: text: 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)
replies: text:  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)
thread_title:  einleitung 

message: 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)
replies: text: Service: SPDY. --46.115.87.158 11:27, 27. Mai 2013 (CEST)
thread_title:  SPDY 

message: 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)
replies: text: "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)
thread_title:  ISO/OSI-Referenzmodell 

message: 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)
thread_title:  infographiken 

message: 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)
replies: text: 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)

text: "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)
thread_title:  HTTP2.0 

message: 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)
replies: text: Stammt offensichtlich aus einer Zeit vor der Verbreitung von RESTful Services. PATCH Methode fehlt auch. --Häuslebauer (Diskussion) 10:05, 5. Sep. 2016 (CEST)
thread_title:  "DELETE ... kaum implementiert beziehungsweise in der Standardkonfiguration von Webservern abgeschaltet" 

message: ; 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.RFC 7127 - Characterization of Proposed Standards 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)
replies: text: 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)
thread_title:  PATCH "noch nicht verabschiedet"? 

message: 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 , , .
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)
replies: text: 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)
thread_title:  Länge des URIs bei GET 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Digest Access Authentication