Reader zum MOOC "Web-Engineering" Kapitel 3: Grundlagen des Webs: HTTP
Die PDF-Datei wurde mit Hilfe des Open-Source-Werkzeugs „mwlib“ erstellt. Für weitere Informationen siehe http://code.pediapress.com/ PDF generated at: Fri, 01 Nov 2013 08:27:14 UTC Inhalt
Artikel
Kapitel 3: Grundlagen des Webs: HTTP 1 World Wide Web 1 Website 5 Representational State Transfer 8 Hypertext Transfer Protocol 13 Hypertext 21 Uniform Resource Locator 24 Clean URL 30 Quellennachweise Quelle(n) und Bearbeiter des/der Artikel(s) 32 Quelle(n), Lizenz(en) und Autor(en) des Bildes 33 Artikellizenzen Lizenz 34 1
Kapitel 3: Grundlagen des Webs: HTTP
World Wide Web
Das World Wide Web [ˌwɜːldˌwaɪdˈwɛb] (kurz Web oder WWW aus dem Englischen für: „Weltweites Netz“) ist ein über das Internet abrufbares System von elektronischen Hypertext-Dokumenten, sogenannten Webseiten. Sie sind durch Hyperlinks untereinander verknüpft und werden im Internet über die Protokolle HTTP bzw. HTTPS übertragen. Die Webseiten enthalten Informationen, die meist in Form von Text vorliegen, der oft mit Fotos und grafischen Elementen illustriert ist. Häufig sind auch Videos, Tondokumente oder Musikstücke in den Webseiten eingebettet. Das historische WWW-Logo, entworfen von Zur Nutzung des World Wide Web wird ein Webbrowser benötigt, der Robert Cailliau üblicherweise auf einem Computer oder Mobilgerät läuft. Mit ihm kann der Benutzer die auf einem Webserver bereitgestellten Webseiten-Daten herunterladen und sich auf dem Bildschirm anzeigen lassen. Der Benutzer kann den Hyperlinks auf einer Webseite folgen, die wiederum auf andere Webseiten verweisen, gleichgültig ob sie auf demselben Webserver oder einem anderen gespeichert sind. Dadurch ergibt sich ein weltweites Netz aus Webseiten. Das Verfolgen der Hyperlinks wird oft als Internetsurfen bezeichnet. Mit dem so genannten Web 2.0 wurden ab etwa den 2000er Jahren Webseiten populär, deren Inhalt der Nutzer nicht nur wie etwa bei Nachrichten-Seiten passiv ansehen, sondern selbst ändern und Grafische Darstellung einiger weniger Sites im World Wide Web um en.wikipedia.org am 18. ergänzen kann, z.B. um eigene Inhalte zu veröffentlichen oder mit Juli 2004 anderen Nutzern zu kommunizieren. Dazu zählen Blogs als private Meinungsseiten, von multiplen Autoren geschaffene Seiten nach dem Wiki-Prinzip und Soziale Netzwerke.
Das WWW wurde unter Weiterentwicklung bekannter ähnlicher Konzepte 1989 von Tim Berners-Lee und Robert Cailliau am europäischen Forschungszentrum CERN entwickelt. Berners-Lee entwickelte dazu das HTTP-Kommunikationsprotokoll und die Seitenbeschreibungs-Sprache HTML. Zudem programmierte er den ersten Web-Browser und die erste Webserver-Software. Er betrieb auch den ersten Webserver der Welt auf seinem Entwicklungsrechner vom Typ NeXTcube. Das Gesamtkonzept wurde der Öffentlichkeit 1991 unter Verzicht auf jegliche Patentierung oder Lizenzzahlungen zur freien Verfügung gestellt, was erheblich zur heutigen Bedeutung beitrug. Das WWW wird im allgemeinen Sprachgebrauch oft mit dem Internet gleichgesetzt, obwohl es jünger ist und nur eine von mehreren möglichen Nutzungen des Internets darstellt. Andere Internet-Dienste wie E-Mail, IRC und Telnet sind nicht in das WWW integriert. Das WWW führte zu umfassenden, oft als revolutionär beschriebenen Umwälzungen in vielen Lebensbereichen, zur Entstehung neuer Wirtschaftszweige und zu einem grundlegenden Wandel des Kommunikationsverhaltens und der Mediennutzung. Es wird in seiner kulturellen Bedeutung, zusammen mit anderen Internet-Diensten wie E-Mail, teilweise mit der Erfindung des Buchdrucks gleichgesetzt. World Wide Web 2
Geschichte
Entwicklung
Das Web entstand 1989 als Projekt an der Forschungseinrichtung CERN, in der Nähe von Genf auf schweizerischem und französischem Gebiet liegend, an dem Tim Berners-Lee ein Hypertext-System aufbaute. Das Konzept wurde von dem Belgier Robert Cailliau mitentworfen. Das ursprüngliche Ziel des Systems war es, Forschungsergebnisse auf einfache Art und Weise mit Kollegen auszutauschen. Eine Methode dafür war das „Verflechten“ von wissenschaftlichen Artikeln – also das Erstellen eines Webs. In Berners-Lees eigenen Worten: Erster Webserver von Tim Berners-Lee
“The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents.” „Das World Wide Web ist eine großräumige Hypermedia-Initiative zur Informationsbeschaffung mit dem Ziel, den allgemeinen Zugang zu einer großen Sammlung von Dokumenten zu erlauben.“ – Tim Berners-Lee Das dem Hypertext zugrunde liegende Konzept stammt von früheren Entwicklungen ab, wie Ted Nelsons Projekt Xanadu, Vannevar Bushs „memex“ Maschinenidee und dem Note Code Project. Das World Wide Web unterscheidet sich von damaligen Hypertext-Systemen (Note Code benutzte beispielsweise eine einfache und lesbare Syntax und sogar semantische Deskriptoren). Das WWW benötigt nur unidirektionale Links statt bidirektionaler, was es ermöglicht, einen Link auf eine Ressource zu setzen, ohne dass deren Besitzer eingreifen muss. Zudem, anders als andere Protokolle wie Tim Berners-Lee (2009) HyperCard oder Gopher, baut das World Wide Web auf einem freien Protokoll auf, was die Entwicklung von Servern und Clients ohne Beschränkungen durch Lizenzen möglich machte. Tim Berners-Lee machte das World Wide Web-Projekt am 6. August 1991 mit einem Beitrag zur Newsgroup alt.hypertext öffentlich und weltweit verfügbar.[1]
Das erste Web-Anzeigeprogramm, das eher ein Browser-Editor-Hybrid war, nannte Berners-Lee einfach „WorldWideWeb“. Er hatte es im Herbst 1990 auf einem NeXT-Computer geschrieben. Später benannte er es – um Verwechslungen mit dem World Wide Web (mit Leerzeichen) zu vermeiden – in „Nexus“ um. Es konnte damals nur Text anzeigen, aber spätere Browser wie Pei Weis Viola (1992) fügten die Fähigkeit Grafiken anzuzeigen hinzu. Marc Andreessen vom NCSA veröffentlichte im Jahre 1993 einen Browser namens „Mosaic für X“, der bald dem Web und auch dem gesamten Internet ungekannte Popularität jenseits der bisherigen Nutzerkreise und ein explosionsartiges Wachstum bescherte. Marc Andreessen gründete die Firma „Mosaic Communications Corporation“, später „Netscape Communication“. Mittlerweile können moderne Browser auch zusätzliche Merkmale wie dynamische Inhalte, Musik, Animationen und Videos wiedergeben. World Wide Web 3
Name In Berners-Lees erstem Projektentwurf vom März 1989 hieß das Web noch Mesh (engl. Geflecht). Der Name wurde aber schnell verworfen, da er zu sehr an Mess (engl. Unordnung) erinnert. Die folgenden Benennungsversuche Mine of Information (engl. Informations-Mine) oder The Information Mine hatten keinen Bestand, da die Abkürzungen MOI (frz. ich) und TIM zu egozentrisch wirkten. Außerdem war eine Mine ein nur teilweise geeignetes Bild, da man aus ihr bloß etwas herausholen kann, das Web dagegen sowohl Informationen liefern als auch mit ihnen befüllt werden sollte. Schließlich legte Berners-Lee sich auf Web und World Wide Web fest, obwohl er von Kollegen gewarnt wurde, dass die im Englischen und Französischen zungenbrecherische Abkürzung WWW den Projekterfolg gefährden würde. Web erschien ihm als Bild besonders passend, da es in der Mathematik ein Netz von Knoten (engl. Nodes) bezeichnet, von denen jeder mit jedem verbunden sein kann.[2]
Funktionsweise Das WWW basiert auf drei Kernstandards: • HTTP als Protokoll, mit dem der Browser Informationen vom Webserver anfordern kann. • HTML als Dokumentenbeschreibungssprache, die festlegt, wie die Information gegliedert ist und wie die Dokumente verknüpft sind (Hyperlinks). • URLs als eindeutige Bezeichnung einer Ressource, die in Hyperlinks verwendet wird. Folgende Standards kamen später dazu: • Cascading Style Sheets (CSS) legen das Aussehen der Elemente einer Webseite fest, wobei Darstellung und Inhalt getrennt werden. • Hypertext Transfer Protocol Secure (HTTPS) ist eine Weiterentwicklung von HTTP, bei dem das Protokoll SSL zwischen TCP und HTTP geschoben wird und in der Folge der Datentransfer komplett verschlüsselt wird. • Document Object Model (DOM) als Programmierschnittstelle für externe Programme oder Skriptsprachen von Webbrowsern. Nicht vom W3-Konsortium standardisiert ist die am weitesten verbreitete Skript- bzw. Makrosprache von Webbrowsern: • JavaScript ist eine Skriptsprache mit Anweisungen für den Browser, mit der Programme (Skripte) eingebettet werden können. Dadurch können Webseiten mit Hilfe des Document Object Models (DOM) dynamisch geändert werden. Skripte sind üblicherweise kleine Programmschnipsel, können aber auch als Client Manager mit Hilfe des DOM die vollständige Kontrolle über die Anzeige übernehmen. Eine von Microsoft entwickelte Variante von JavaScript heißt JScript. Beide Sprachen sind sich ähnlich, allerdings nicht kompatibel zueinander. Diese Inkompatibilität der beiden Sprachen war ein entscheidender Teil des sogenannten Browserkriegs. Das World Wide Web Consortium (auch W3C genannt), das heute vom Erfinder des WWW, Tim Berners-Lee, geleitet wird, entwickelt den HTML- und CSS-Standard; andere Standards stammen von der Internet Engineering Task Force, der ECMA oder Herstellern wie Sun Microsystems. Das WWW wurde und wird durch andere Technologien ergänzt. Schon sehr früh wurden Bilder zur Illustration benutzt; die Formate GIF, PNG und JPEG herrschen vor. Zudem können in Browsern zahlreiche weitere Dateitypen durch Browsererweiterungen, so genannte Plug-ins, dargestellt werden. Dadurch lassen sich Multimediainhalte von Animationen bis hin zu Musik und Videos oder ganze Anwendungen wie zum Beispiel Versicherungsrechner oder Navigationsoberflächen darstellen. Ferner ermöglichen Java-Applets das Einbetten von Programmen, die auf dem Computer des WWW-Benutzers ablaufen. Weitere beliebte Formate sind PDF zum Anzeigen von Dokumenten bzw. Flash für interaktive Inhalte oder Animationen. World Wide Web 4
Dynamische Webseiten und Webanwendungen → Hauptartikel: Webanwendung Mit Hilfe der dynamischen WWW-Seiten kann das WWW als Oberfläche für verteilte Programme dienen: Ein Programm wird nicht mehr konventionell lokal auf dem Rechner gestartet, sondern ist eine Menge von dynamischen WWW-Seiten, die durch einen Webbrowser betrachtet und bedient werden können. Vorteilhaft ist hier, dass die Programme nicht mehr auf den einzelnen Rechnern verteilt sind und dort (dezentral) administriert werden müssen. Dynamische Webanwendungen werden entweder am Webserver oder direkt im Browser ausgeführt. • Ausführen von Webanwendungen am Webserver: Der Inhalt wird durch in Skriptsprachen (wie PHP oder Perl) oder kompilierte Anwendungen (wie JSP, Servlets oder ASP.NET) geschriebene Webanwendungen erzeugt und an den Browser geliefert. • Dynamische Websites am Client: Der Browser erzeugt oder ändert Inhalt mittels JavaScript. • Gemischte Ausführung: Eine gemischte Ausführung stellt AJAX dar – hier sendet der Browser mittels JavaScript einen Request, der vom Webserver bearbeitet wird und so dynamisch Teile der HTML-Struktur erneuert. Nachteilig sind die begrenzten Ausdrucksmöglichkeiten von WWW-Seiten, so dass Programme in Form von Internetseiten im Allgemeinen nicht so einfach bedient werden können wie konventionelle Programme. Ein Trend, der versucht, beides in Einklang zu bekommen, sind Rich Internet Applications. Zurzeit ist zu beobachten, dass immer mehr Dienste, die ursprünglich vom WWW getrennt waren und als eigenes Programm liefen, über das WWW angeboten werden und mittels eines Browsers genutzt werden können: So wird Webmail oft als E-Mail-Client oder WebFTP als FTP-Client genutzt; Webforen ersetzen das Usenet und Webchats den IRC.
Kompatibilität und Zugänglichkeit Oft führten Browser-Hersteller neue Möglichkeiten ein, ohne auf eine Standardisierung zu warten. Umgekehrt werden jedoch immer noch nicht alle Teile von Standards wie HTML oder CSS korrekt implementiert. Das führt zu Inkompatibilitäten zwischen bestimmten Webseiten und manchen Browsern. Besonders „hervorgetan“ durch solche Inkompatibilitäten hatte sich zu Beginn des Internet-Booms die Firma Netscape, heute vor allem das Unternehmen Microsoft mit seinem Internet Explorer. Außerdem ging durch die Vielzahl der Ad-Hoc-Erweiterungen von HTML ein wesentlicher Vorteil dieser Sprache verloren – die Trennung von Inhalt und Darstellung. Durch diese Trennung können die in HTML ausgezeichneten Inhalte optimal für das jeweilige Ausgabegerät – ob Bildschirm, Display des Mobiltelefons oder Sprachausgabe (für Benutzer mit Sehschwierigkeiten) – aufbereitet werden. Das W3C und andere Initiativen treiben daher die Entwicklung in die Richtung XHTML/XML und CSS voran, um diese Vorteile von HTML wiederzuerlangen. Die fortschreitenden Bemühungen um die Barrierefreiheit von Internetseiten unterstützen diesen Trend.
Literatur • Tim Berners-Lee, Mark Fischetti: Der Web-Report. Der Schöpfer des World Wide Webs über das grenzenlose Potential des Internets. Econ, München 1999 (Originaltitel: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web (Paperback: 2000)), ISBN 3-430-11468-3. • Christoph Meinel, Harald Sack: WWW – Kommunikation, Internetworking, Web-Technologien [3]. Springer, Berlin, Heidelberg, New York 2004, ISBN 3-540-44276-6. World Wide Web 5
Weblinks • Tim Berners-Lee: Information Management: A Proposal [4], März 1989. • Die Geschichte des World Wide Web [5], netplanet.org • Zeitleiste der Geschichte des WWW mit Emulationen alter Dienste und Browser [6] (englisch) • World Wide Web Consortium [7], dort die erste WWW-Seite (Archiv) [8] (englisch) • Erste Website, wieder hergestellt [9] • Matthias Gräbner: Das Internet ist keine Zwiebel [10]. In: Telepolis, 23. Juni 2007.
Einzelnachweise
[1] Tim Berners-Lee: WorldWideWeb - Executive Summary (http:/ / groups. google. com/ group/ alt. hypertext/ msg/ 395f282a67a1916c), 6. August 1991 [2] Berners-Lee, Fischetti 2000, S. 23.
[3] http:/ / www. minet. uni-jena. de/ ~sack/ WWWBuch/
[4] http:/ / www. w3. org/ History/ 1989/ proposal. html
[5] http:/ / www. netplanet. org/ geschichte/ worldwideweb. shtml
[6] http:/ / www. dejavu. org
[7] http:/ / www. w3. org
[8] http:/ / www. w3. org/ History/ 19921103-hypertext/ hypertext/ WWW/ TheProject. html
[9] http:/ / info. cern. ch/ hypertext/ WWW/ TheProject. html
[10] http:/ / www. heise. de/ tp/ r4/ artikel/ 25/ 25553/ 1. html
Normdaten (Sachbegriff): GND: 4363898-3 (http:/ / d-nb. info/ gnd/ 4363898-3)
Website
Eine Website (englische Aussprache [ˈwɛbsaɪt]; von englisch site für ‚Ort‘, ‚Platz‘, ‚Stelle‘ und von lateinisch situs für ‚Lage‘ oder ‚Stellung‘) – im deutschen Sprachgebrauch auch Webauftritt (Internetauftritt), Webpräsenz (Internetpräsenz), Webangebot (Internetangebot) sowie Internetplattform (Webplattform) genannt – ist ein virtueller Platz im World Wide Web, an dem sich meist mehrere Webseiten (Dateien) und andere Ressourcen befinden. Diese sind üblicherweise durch eine einheitliche Navigation (durch Hypertext-Verfahren) zusammengefasst und verknüpft. So ist etwa die Wikipedia als Gesamtes eine Website, die im Internet auf einem oder mehreren Host-Rechnern (Servern) gespeichert ist, während das, was im Browser angezeigt wird, speziell als ein einzelnes Dokument betrachtet wird. Die Website der deutschsprachigen Wikipedia umfasst derzeit über vier Millionen Webseiten.
Begriffsbestimmung Eine Website umfasst alle einem Privatanbieter oder Unternehmen gehörenden Webseiten und evtl. downloadbaren Dokumente im WWW, die unter einer bestimmten Domain zusammengefasst sind.[1] Letztlich ist die Website ein Medium, um über das Internet zu kommunizieren. Mit Hilfe vielfältiger Kommunikationsangebote baut eine Website eine Beziehung zwischen dem Anbieter, dem Betreiber und dem Nutzer (User) der Website auf. Der Übergang der Schreibweise von World Wide Web Site zu einem einzigen, im Englischen kleingeschrieben Wort website spiegelt die typische Weiterentwicklung technischer Ausdrücke wider. Diese Weiterentwicklung basiert dahingehend, dass das Schriftbild eher die Form ohne Bindestrich annimmt, um für die Allgemeinheit besser vertraut zu werden. Ebenso besteht eine zunehmende Präferenz auf geschlossene Formen wie eben website, homepage, online usw.[2] Führende Nachrichtenagenturen wie z. B. Reuters oder The Chicago Manual empfehlen im Englischen die Schreibweise website. Unter den führenden Wörterbüchern wie etwa das kanadische Oxford Dictionary und weitere Website 6
Enzyklopädien wird ebenso das Schriftbild website verwendet.[3] Bei großen Internetkonzernen wie z. B. Google und Apple ist die Verwendung der Schreibweise website zu erkennen. Microsoft hingegen nutzt beide Schreibweisen, sowohl website als auch web site. Website, Webpräsenz sowie Internetplattform, Internetauftritt und Internetpräsenz werden im Allgemeinen synonym verwendet.[4] Im Fachdiskurs wird manchmal Internetpräsenz (Webanwendungen + Dienste/Daemons wie FTP und E-Mail) weiter gefasst als Webpräsenz (nur Webanwendungen). Während Internetplattform im Allgemeinen synonym mit Website verwendet wird, wird Webplattform häufig nur in einem Teil der Fälle synonym mit Website verwendet, siehe Begriffsklärungsseite Webplattform.
Geschichte Die erste Website, die sozusagen online ging, wurde am 13. November 1990 von dem am CERN beschäftigten Wissenschaftler Tim Berners-Lee geschaffen und veröffentlicht. Am 30. April 1993 kündigte das CERN an, dass das World Wide Web für jedermann frei zugänglich sein werde.
Bestandteile Eine Website besteht im einfachsten Fall zumindest aus einer HTML-Datei, die in einem Verzeichnis im Pfad einer Domain liegt. Im Allgemeinen ist sie heute aber aus zahlreichen HTML-Dateien aufgebaut, die auch in einer verschachtelten Verzeichnisstruktur untergebracht werden können. Außerdem ist zu beachten, dass eine HTML-Datei selbst meist aus einer Datei mit der Endung .html oder auch .htm und einem gleichnamigen Verzeichnis besteht, in dem die nicht HTML-konformen Elemente (Bilder, Medien usw.) untergebracht sind; dazu gehören Dateien über die CSS-Klassentypisierungen und diverse Skriptdateien (JavaScript). So stellt es sich zumindest dar, wenn die angezeigte Seite vom Browser auf der Festplatte des Besuchers abgespeichert wird; intern kann sie synthetisch vollständig durch Skriptsprachen und Datenbankinhalte erzeugt sein, so dass die Existenz einer echten Datei lediglich vorgetäuscht wird (teilweise deshalb, weil man sich davon bessere Positionen bei Suchmaschinen verspricht). CSS und JavaScript-Dateien werden typischerweise für eine Website zentral vorgegeben und bei Massenhostern sogar vom Provider für den ganzen Webspace vorgegeben. Eine Homepage ist die Seite eines Web-Auftrittes, die als zentraler Dreh- und Angelpunkt angelegt ist. Die Startseite (auch Eintritt-, Index-Seite) ist die erste aufgerufene Seite einer Website. In den meisten Fällen ist die Homepage auch die Startseite einer Website. In besonderen Fällen ist ihr jedoch eine Intro-Seite vorgeschaltet. Dies in der Regel deshalb, weil anschließend eine Frame-Lösung gezeigt wird, deren Erfassung durch Suchmaschinen oft nicht optimal ist. Das Intro soll dann über die für den Besucher unsichtbaren, für Suchmaschinen bestimmten Inhalte und Stichworte die nötigen Informationen liefern, sofern die Folgeseiten für diese unsichtbar bleiben. Daher erscheint das Intro oft extrem spartanisch und sagt für den Besucher nichts aus; es wird oft als lästig und als Hindernis empfunden. Vielfach wird versucht dem mit Flash-Animationen zu begegnen, die jedoch von vielen Besuchern ebenfalls als Zumutung und Zeitverschwendung betrachtet werden. Als Reaktion darauf wird meist ein Link zum Überspringen angeboten.
Technische Umsetzung Websites werden vorwiegend in der plattformunabhängigen Auszeichnungssprache HTML oder XHTML geschrieben, um zu gewährleisten, dass sie von möglichst allen Browsern dargestellt werden können. Heute werden Websites mit CSS gestaltet, denn diese ermöglichen eine einfache Gestaltung von Inhalten, die mit HTML oder XHTML strukturiert wurden. Bei aufwendigeren Websites erfolgt das Erzeugen des HTML-Quelltextes meist unter Verwendung serverseitiger Skript- (PHP, Perl, Python, Ruby, VBScript) oder Programmiersprachen (Java), die unter anderem auch die Verwendung von Datenbanksystemen (MySQL, PostgreSQL, Oracle) erlauben. Oft kommen auch clientseitige Skriptsprachen wie JavaScript zum Einsatz, die normalerweise mehr für die Benutzerinteraktion als für Website 7
die vollständige Erstellung einer Website verwendet werden. Serverseitige Skripte oder Programme erzeugen als Ausgabe vorzugsweise HTML-Text, der dann vom Browser des Benutzers gerendert wird. Die Website wird auf einem Webserver abgelegt, der häufig in einem Rechenzentrum von einem so genannten Webhoster betrieben und an den Inhaber der Website vermietet wird. Die Entwicklung von Websites wird als Webdesign oder Webauthoring bezeichnet.
Zwecke • Rein private Selbstdarstellung, in der sich jemand mit seinen persönlichen Angaben (Name, Anschrift, Geburtstag usw.), seinen Interessen, Fotos, einem Online-Tagebuch und einem Gästebuch darstellt, in dem Besucher ihre Kommentare zu der Gestaltung und dem Inhalt des Angebotes abgeben können. Gegen die Angabe allzu persönlicher Daten spricht, dass Kriminelle solche Angaben für ihre Ziele missbrauchen könnten. • Halb private Darstellung in so genannten Weblogs, die meist privater Natur sind und einem offenen Online-Tagebuch gleichen, bei dem die Besucher zu den Inhalten der Seite beitragen können, sowie in Foren, die sich mit teils sehr speziellen Themenbereichen beschäftigen und wo jeder seine Fragen, Antworten und Meinungen in den öffentlichen Raum des Internets stellen kann. In beiden Formen wird Wert auf höflichen Umgang gelegt. Wird mehrfach oder zu stark gegen die Regeln des Anstandes verstoßen, ist ein Ausschluss aus dem Forum möglich. • Rein informative Darstellung geschäftlicher oder privater Art, mit der entweder eine Organisation oder ein Unternehmen sich und das dazugehörige Tätigkeitsfeld oder eine Privatperson ihre Qualifikationen und bisherigen Tätigkeiten (Bewerberwebsite) vorstellt, wobei besonderer Wert auf die verschiedenen Kontaktmöglichkeiten (Telefon, Fax, E-Mail usw.) gelegt wird. Siehe dazu auch Wikibooks Bewerberhomepage. • Verkaufsbezogene Webpräsenzen von Unternehmen, deren Hauptbetätigungsfeld der Handel im Netz ist, wie z. B. Online-Auktionshäuser, Versandhäuser, Online-Shops oder Online-Versicherungen. Solche Webpräsenzen stellen im Web Produkte und Dienstleistungen vor, um Besuchern Angebote zu machen und um Aufträge zu erhalten oder zu vermitteln. • Themenbezogene Webangebote, die dazu dienen, über einen bestimmten Inhalt umfassend zu informieren, wie z. B. Gesetzestexte, Kulturprogramme oder Lexika. Der technische Vorteil einer einfacheren Aktualisierung gegenüber gedruckten Angeboten wird jedoch nicht immer genutzt. Es können Ghost Sites entstehen. • Nachrichten-Websites, auf der die neuesten Nachrichten entweder allgemein oder nur für einen bestimmten gesellschaftlichen Bereich angeboten werden. Oft sind auf diesen Seiten auch RSS-Feeds zu finden. Finanziert werden Websites häufig durch Anzeigen.
Meist aufgerufene Websites Die 18 am meisten aufgerufenen Websites sind:
[5] [6] Nr. Weltweit Deutschland
1 Google.com Google.de
2 Facebook Facebook
3 YouTube YouTube
4 Yahoo! Amazon
5 Baidu eBay
6 Wikipedia Google.com
7 Windows Live Wikipedia
8 QQ Web.de Website 8
9 Amazon Yahoo!
10 Twitter Bild.de
11 Blogspot T-Online
12 Taobao GMX
13 LinkedIn Spiegel Online
14 Google India Conduit
15 Yahoo! Japan Uimserv
16 Bing Chip.de
17 MSN Windows Live
18 eBay xHamster
Einzelnachweise
[1] vgl. duden.de, Lemma „Website“ (http:/ / www. duden. de/ suchen/ dudenonline/ website)
[2] The free dictionary – Begriffsbestimmung (http:/ / www. thefreedictionary. com/ website) – abgerufen am 12. Februar 2013
[3] Was ist eine Website – Überblick (http:/ / www. dimaweb. at/ was-ist-eine-website. html) – abgerufen am 10. Februar 2013
[4] Bedeutungswörterbuch – Synonyme und Begriff (http:/ / www. canoo. net/ services/ Controller?input=Website) – abgerufen am 10. Februar 2013
[5] http:/ / www. alexa. com/ topsites und http:/ / mostpopularwebsites. net/
[6] http:/ / www. alexa. com/ topsites/ countries/ DE
Normdaten (Sachbegriff): GND: 4596172-4 (http:/ / d-nb. info/ gnd/ 4596172-4)
Representational State Transfer
Representational State Transfer (mit dem Akronym REST, seltener auch ReST) bezeichnet ein Programmierparadigma für Webanwendungen. Es gibt keine explizite Norm, daher gehen die Vorstellungen, was REST ist, auseinander. Im Grunde bezeichnet REST die Idee, dass eine URL genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion (etwa das Anzeigen einer Trefferliste nach einer Suche) darstellt, wie es der Internetstandard HTTP für statische Inhalte (Permalinks) bereits vorsieht; ein Ziel, das für dynamisch erzeugte Seiten mitunter jedoch zusätzlichen Aufwand erfordert.
Geschichte REST stammt aus der Dissertation von Roy Fielding aus dem Jahr 2000, in der er den Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückführt. Fielding war zuvor auch an der Spezifikation des Hypertext-Transfer-Protokolls (HTTP) beteiligt. REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die die Implementierung verteilter webbasierter Systeme vereinfachen soll. Representational State Transfer 9
Prinzipien Es gibt fünf Eigenschaften, die ein REST-Dienst haben muss, wobei es den einzelnen Diensten überlassen ist, wie es implementiert wird.
Adressierbarkeit Jeder Dienst, den ein REST-konformer Server zur Verfügung stellt, hat eine eindeutige Adresse, den Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ stellt sicher, dass das Angebot eines Webservices auf einfache, standardisierte Art und Weise einer Vielzahl von Anwendungen (Clients) zur Verfügung steht. Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden. Zusätzlich zur URL, der den Service selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.
Unterschiedliche Repräsentationen Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen ausliefern (z. B. HTML, JSON oder XML). Damit kann der Standard-Webbrowser über die gleiche URI-Adresse sowohl den Dienst, als auch die Beschreibung oder Dokumentation abrufen. Es wird nicht der interne Datenbankeintrag ausgeliefert, sondern das je nach Anfrage evtl. in eine bestimmte Kodierung oder Sprachversion übertragene Dokument.
Zustandslosigkeit REST setzt auf ein zustandsloses Client-Server-Protokoll, wobei im Normalfall HTTP oder HTTPS eingesetzt wird. Jede REST-Nachricht enthält dabei alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Eine derartig strikte Trennung der Zuständigkeiten zwischen Client und Server führt dazu, dass ein REST-konformer Webservice als zustandslos (englisch: stateless) bezeichnet werden kann. Jede Anfrage eines Clients an den Server ist in dem Sinne in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt werden. Zustandslosigkeit in der hier beschriebenen Form wirkt sich begünstigend auf die Skalierbarkeit eines Webservices aus. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden: Da jeder Request in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden, ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen jedoch viele HTTP-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen zu behalten.
Operationen REST-konforme Dienste müssen einige Operationen vorsehen, die auf alle Dienste (Ressourcen genannt) angewendet werden können. HTTP zum Beispiel hat eine klar definierte Menge von Operationen, darunter GET, POST, PUT und DELETE. HTTP schreibt vor, dass GET „sicher“ (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Representational State Transfer 10
Verwendung von Hypermedia Sowohl für Anwendungsinformationen als auch für Zustandsveränderungen werden Hypermedia benutzt: Repräsentationen in einem REST-System sind typischerweise im HTML- oder XML-Format, welche sowohl Informationen als auch Links zu anderen Ressourcen enthalten. Deshalb ist es oftmals möglich, von einer Ressource zu einer anderen zu navigieren, indem man einfach Verknüpfungen folgt, ohne dass dafür Registrierungsdatenbanken oder ähnliche Infrastrukturen erforderlich sind. Diese Verknüpfung von Ressourcen innerhalb einer REST-Architektur wird auch als Verbindungshaftigkeit bezeichnet.
Umsetzung REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und – bezüglich des zu erwartenden Verhaltens – standardisierte Menge von Aktionen („Verben“). Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert. Für die Umsetzung des REST-Architekturstils werden meist Internet-Technologien verwendet, als Anwendungsschicht-Protokoll dient hauptsächlich HTTP. Der Client kann folgende Befehle absetzen
Befehl Beschreibung Anmerkungen (HTTP-Verb)
GET fordert die angegebene Ressource vom Server an. GET weist keine Nebeneffekte auf. Der Zustand am Server wird nicht verändert, weshalb GET als sicher bezeichnet wird.
POST fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keine URI besitzt, adressiert den URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden Operationen abzubilden, die von keiner anderen Methode abgedeckt werden.
PUT die angegebene Ressource wird angelegt. Wenn die Ressource bereits existiert, wird sie geändert.
PATCH ein Teil der angegeben Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt.
DELETE löscht die angegebene Ressource. Wenn der Client versucht, eine Ressource zu löschen, die nicht existiert bzw. bereits gelöscht wurde, erhält der Client – sofern die REST-Schnittstelle korrekt implementiert wurde – keine Fehlermeldung (siehe auch: HTTP-Statuscodes). Abhängig von der Implementierung wird eine Ressource meist – entgegen der HTTP-Spezifikation – nicht physisch gelöscht, sondern nur als gelöscht gekennzeichnet und somit versteckt und deaktiviert.
HEAD fordert Metadaten zu einer Ressource vom Server an.
OPTIONS prüft, welche Methoden auf einer Ressource zur Verfügung stehen.
CONNECT Dient dazu die Anfrage durch einen TCP-Tunnel zu leiten. Wird meist eingesetzt um eine HTTPS-Verbindung über einen HTTP-Proxy herzustellen.
TRACE Gibt die Anfrage zurück, wie sie der Zielserver erhält. Dient etwa dazu um Änderungen der Anfrage durch Proxyserver zu ermitteln.
Im Gegensatz zu vielen RPC-Architekturen kodiert REST keine Methodeninformation in den URI, da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die die Ressource anbietet. Es wird versucht, die Funktionalität hauptsächlich über die HTTP-Verben abzubilden. Representational State Transfer 11
Sicherheit In der Theorie verlangt das Paradigma, dass alle Informationen, die eine Anwendung braucht, um den Seitenzustand wieder herzustellen, in der Anfrage enthalten sind. Dabei identifiziert der URI die Ressource während im HTTP-Header Informationen wie Zugriffsart (GET, PUT), Rückgabeformat oder Authentifizierung enthalten sein können. In seiner Reinform lässt sich REST für Webseiten und Webservices verwenden, die keine Authentifizierung erfordern oder diese auf anderem Wege (beispielsweise durch Prüfung der IP-Adresse oder über HTTP-Authentifizierung) erreichen, wodurch bereits viele Anwendungsfälle abgedeckt werden können. Alternativ kann beispielsweise auch HMAC, OAuth oder OpenID verwendet werden. Da REST – im Gegensatz zu SOAP mit WS-Security – selbst keine Verschlüsselungsmethoden definiert, wird bei sicherheitskritischen Nachrichten ein verschlüsseltes Transportprotokoll wie HTTPS verwendet.
HATEOAS Hypermedia as the Engine of Application State, kurz HATEOAS, ist ein Entwurfsprinzip von REST-Architekturen. Bei HATEOAS navigiert der Client einer REST-Schnittstelle ausschließlich über URLs, welche vom Server bereitgestellt werden. Abhängig von der gewählten Repräsentation geschieht die Bereitstellung der URIs über Hypermedia, also z. B. • in Form von „href“- und „src“-Attributen bei HTML-Dokumenten bzw. HTML-Snippets, oder • in für die jeweilige Schnittstelle definierten und dokumentierten JSON- bzw. XML-Attributen bzw. -Elementen. Abstrakt betrachtet stellen HATEOAS-konforme REST-Services einen endlichen Automaten dar, dessen Zustandsveränderungen durch die Navigation mittels der bereitgestellten URIs erfolgt. Durch HATEOAS ist eine lose Bindung gewährleistet und die Schnittstelle kann verändert werden. Im Gegensatz dazu kommuniziert ein SOAP-basiertes Webservice über ein fixiertes Interface. Für eine Änderung des Services muss hier eine neue Schnittstelle bereitgestellt werden und in der Schnittstellenbeschreibung (ein WSDL-Dokument) definiert werden.
REST Maturity Model Das REST Maturity Model (REST-Reifegradmodell), kurz RMM, ist ein von Leonard Richardson entwickelter Maßstab, der angibt wie stark ein Service auf REST basiert.
REST Maturity Model
Level Eigenschaften
0 • verwendet XML-RPC oder SOAP • der Service wird über eine einzelne URI adressiert • verwendet eine einzelne HTTP-Methode (POST)
1 • verwendet verschiedene URIs und Ressourcen • verwendet eine einzelne HTTP-Methode (POST)
2 • verwendet verschiedene URIs und Ressourcen • verwendet mehrere HTTP-Verben
3 • basiert auf HATEOAS; verwendet Hypermedia für Navigation • verwendet verschiedene URIs und Ressourcen • verwendet mehrere HTTP-Verben Representational State Transfer 12
Abgrenzung zu anderen Kommunikationsmechanismen Bei REST handelt es sich um ein Entwurfsmuster, welches mit verschiedenen Mechanismen implementiert werden kann. Eine Neuerung ist dabei die Verwendung von möglichst vielen HTTP-Verben in Verbindung mit der auszuführenden Aktion. Im Gegensatz dazu wurde zum Beispiel SOAP im Wesentlichen mit den Verben GET und PUT verwendet. Der Unterschied liegt also mehr in der breiteren Verwendung von HTTP als Protokoll und URI als Identifizierungsmechanismus für konkrete Objekte. In der Vergangenheit wurde im Gegensatz dazu mit SOAP eher ein RPC-basierter Aufbau der Schnittstellen durchgeführt. Durch die starke Vorgabe des Entwurfsmusters bei REST sind solche Dienste per Definition strukturierter gebaut und ermöglicht die Verwendung von Clean URLs.
Literatur • Leonard Richardson, Sam Ruby: Web Services mit REST. O’Reilly Verlag, 1. Oktober 2007, ISBN 978-3897217270. • Stefan Tilkov: REST und HTTP. Einsatz der Architektur des Web für Integrationsszenarien. dpunkt Verlag, 27. Juli 2009, ISBN 978-3898645836. • Jamie Kurtz: ASP.NET MVC 4 and the Web API: Building a REST Service from Start to Finish. Apress, 30. Januar 2013, ISBN 978-1430249771.
Weblinks
• Roy Fielding: Architectural Styles and the Design of Network-based Software Architectures. (http:/ / www. ics.
uci. edu/ ~fielding/ pubs/ dissertation/ top. htm) Abgerufen am 6. April 2013 (englisch, Dissertation von Roy Fielding, in der REST beschrieben wird).
• Roy T. Fielding: REST APIs must be hypertext-driven. (http:/ / roy. gbiv. com/ untangled/ 2008/ rest-apis-must-be-hypertext-driven) 20. September 2008, abgerufen am 7. April 2013 (englisch, Empfehlungen zum Entwerfen von REST-Schnittstellen mit HATEOAS).
• David Megginson: The quick pitch. (http:/ / quoderat. megginson. com/ 2007/ 02/ 15/ rest-the-quick-pitch) In: Quoderat. 15. Februar 2007, abgerufen am 6. April 2013 (englisch, Pragmatische Empfehlungen für die Anwendung von REST).
• Thomas Bayer: REST Web Services. (http:/ / www. oio. de/ public/ xml/ rest-webservices. htm) Orientation in
Objects (http:/ / www. oio. de/ ), November 2002, abgerufen am 6. April 2013 (Einführung in RESTful Web Services).
• Alex Rodriquez: RESTful Web services: The basics. (http:/ / www. ibm. com/ developerworks/ webservices/
library/ ws-restful/ ) In: developerWorks. IBM, 6. November 2008, abgerufen am 6. April 2013 (englisch, Basisprinzipien von REST).
• Stefan Tilkov: REST – Der bessere Web Service? (http:/ / it-republik. de/ jaxenter/ artikel/
REST---Der-bessere-Web-Service-2158. html) In: jaxenter. IT-Republik, Februar 2009, abgerufen am 6. April 2013 (deutsch, Grundlagen der REST-Architektur).
• Gregor Roth: RESTful HTTP in practice. (http:/ / www. infoq. com/ articles/ designing-restful-http-apps-roth) InfoQ, 18. August 2009, abgerufen am 6. April 2013 (REST in der Praxis). • Mathieu Fenniak: The Web API Checklist — 43 Things To Think About When Designing, Testing, and Releasing
your API. (http:/ / mathieu. fenniak. net/ the-api-checklist/ ) 15. April 2013, abgerufen am 16. April 2013 (englisch, Checkliste für die Entwicklung von REST-APIs). Java
• JSR 311. (http:/ / jsr311. java. net/ ) In: java.net (http:/ / java. net/ ). Oracle, abgerufen am 6. April 2013 (englisch, JAX-RS: Java API für RESTful Web Services). Representational State Transfer 13
• Jersey. (http:/ / jersey. java. net/ ) In: java.net (http:/ / java. net/ ). Oracle, abgerufen am 6. April 2013 (englisch, REST-Framework, JAX-RS Referenz-Implementierung).
• Restlet Framework. (http:/ / www. restlet. org/ ) Restlet, abgerufen am 6. April 2013 (englisch, REST-Framework).
• RESTEasy. (http:/ / jboss. org/ resteasy/ ) Jboss, abgerufen am 6. April 2013 (englisch, REST-Framework, JAX-RS Implementierung).
• restfuse: An open-source JUnit extension to test HTTP/REST APIs. (http:/ / restfuse. com) In: EclipseSource Developer. Abgerufen am 6. April 2013 (Framework zum Testen von REST Services).
• REST-assurred. (http:/ / code. google. com/ p/ rest-assured/ ) In: Google Code. Abgerufen am 6. April 2013 (Framework zum Testen von REST Services). .NET
• Web API. (http:/ / www. asp. net/ web-api) In: asp.net (http:/ / asp. net/ ). Microsoft, abgerufen am 6. April 2013 (englisch, ASP.NET MVC API für .NET-basierte REST-Services).
• Jamie Kurtz: ASP.NET Web API REST Security Basics. (http:/ / jamiekurtz. com/ 2013/ 01/ 14/
asp-net-web-api-security-basics/ ) 14. Januar 2013, abgerufen am 7. April 2013 (englisch).
Einzelnachweise
Normdaten (Sachbegriff): GND: 7592728-7 (http:/ / d-nb. info/ gnd/ 7592728-7)
Hypertext Transfer Protocol
HTTP (Hypertext Transfer Protocol)
Familie: Internetprotokollfamilie
Einsatzgebiet: Datenübertragung, Hypertext u. a.
Port: 80/TCP
Anwendung HTTP
Transport TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token Token FDDI … Bus Ring
Standards: RFC 1945 (HTTP/1.0, 1996) RFC 2616 (HTTP/1.1, 1999)
Das Hypertext Transfer Protocol (HTTP, deutsch Hypertext-Übertragungsprotokoll) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten aus dem World Wide Web (WWW) in einen Webbrowser zu laden. HTTP gehört der sogenannten Anwendungsschicht etablierter Netzwerkmodelle an. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall von HTTP ist das meist ein Webbrowser. Im ISO/OSI-Schichtenmodell entspricht die Anwendungsschicht den Schichten 5–7. HTTP ist ein zustandsloses Protokoll. Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine Sitzung über eine Session-ID implementiert werden. Hypertext Transfer Protocol 14
Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Statuscodes ist HTTP nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet, außerdem ist es Grundlage des auf Dateiübertragung spezialisierten Protokolls WebDAV. Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen, wofür in nahezu allen Fällen TCP verwendet wird.
Vorgeschichte Ab 1989 entwickelten Roy Fielding, Tim Berners-Lee und andere am CERN das Hypertext Transfer Protocol, zusammen mit den Konzepten URL und HTML, womit die Grundlagen des World Wide Web geschaffen wurden. Erste Ergebnisse dieser Bemühungen war 1991 die Version HTTP 0.9.[1] Die letztlich im Mai 1996 als RFC 1945 (Request for Comments Nr. 1945) publizierte Anforderung ist als HTTP/1.0 bekannt geworden. 1999 wurde eine zweite Anforderung als RFC 2616 publiziert, die den HTTP/1.1-Standard wiedergibt.[2]
Aufbau Die Kommunikationseinheiten in HTTP zwischen Client und Server werden als Nachrichten bezeichnet, von denen es zwei unterschiedliche Arten gibt: die Anfrage (engl. Request) vom Client an den Server und die Antwort (engl. Response) als Reaktion darauf vom Server zum Client. Jede Nachricht besteht dabei aus zwei Teilen, dem Nachrichtenkopf (engl. Message Header, kurz: Header oder auch HTTP-Header genannt) und dem Nachrichtenkörper (engl. Message Body, kurz: Body). Der Nachrichtenkopf enthält Informationen über den Nachrichtenkörper wie etwa verwendete Kodierungen oder den Inhaltstyp, damit dieser vom Empfänger korrekt interpretiert werden kann. Der Nachrichtenkörper enthält schließlich die Nutzdaten.
Funktionsweise Wenn auf einer Webseite der Link zur URL http://www.example.net/infotext.html aktiviert wird, so wird an den Computer mit dem Hostnamen www.example.net die Anfrage gerichtet, die Ressource /infotext.html zurückzusenden. Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse umgesetzt. Zur Übertragung wird über TCP auf den Standard-Port 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet. Anfrage: GET /infotext.html HTTP/1.1 Host: www.example.net
Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese %-kodiert. Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc. können über den Header (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden. Sobald der Header mit einer Leerzeile (bzw. zwei aufeinanderfolgenden Zeilenenden) abgeschlossen wird, sendet der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der infotext.html-Datei. Übertragen werden normalerweise Dateien in Seitenbeschreibungssprachen wie (X)HTML und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets (CSS), Skripte (JavaScript) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden. Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden zu sein braucht (z. B. bei Anwendung von CGI, SSI, JSP, PHP oder ASP.NET). Jede Zeile im Header wird durch den Zeilenumbruch
HTTP/1.1 200 OK Server: Apache/1.3.29 (Unix) PHP/4.3.4 Content-Length: (Größe von infotext.html in Byte) Content-Language: de (nach RFC 3282 sowie RFC 1766) Connection: close Content-Type: text/html
(Inhalt von infotext.html)
Der Server sendet eine Fehlermeldung sowie einen Errorcode zurück, wenn die Information aus irgendeinem Grund nicht gesendet werden kann, allerdings werden auch dann Statuscodes verwendet, wenn die Anfrage erfolgreich war, in dem Falle (meistens) 200 OK. Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt.
Protokollversionen Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet. Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen. 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 Proxys Probleme bereiten. Mittels HTTP-Pipelining können in der Version 1.1 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Da die Geschwindigkeit von TCP-Verbindungen zu Beginn durch Verwendung des Slow-Start-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden. 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. Dadurch werden Anwendungen möglich, die Status- bzw. Sitzungseigenschaften erfordern. Auch eine Benutzerauthentifizierung ist möglich. Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern gelesen werden, die im Netzwerk durchlaufen werden. Über HTTPS kann die Übertragung aber verschlüsselt erfolgen. Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des MIME-Typs multipart/replace, bei dem der Browser nach Senden eines Boundary-Codes und eines neuerlichen Content-Length-Headerfeldes sowie eines neuen Content-Type-Headerfeldes den Inhalt des Browserfensters neu aufbaut. Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen. Mit Hilfe der PUT-Methode können so Webdesigner ihre Seiten direkt über den Webserver per WebDAV publizieren, und mit der DELETE-Methode ist es ihnen möglich, Daten vom Server zu löschen. Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden. Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxys hinweg zu ermitteln, ein traceroute auf Anwendungsebene. Hypertext Transfer Protocol 16
HTTP-Request-Methoden GET ist die gebräuchlichste Methode. Mit ihr wird eine Ressource (z. B. eine Datei) unter Angabe eines URI vom Server angefordert. Als Argumente in dem URI können also auch Inhalte zum Server übertragen werden, allerdings soll laut Standard eine GET-Anfrage nur Daten abrufen und sonst keine Auswirkungen haben (wie Datenänderungen auf dem Server oder ausloggen). 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. (siehe unten) POST schickt unbegrenzte, je nach physikalischer Ausstattung des eingesetzten Servers, Mengen an Daten zur weiteren Verarbeitung zum Server, diese werden als Inhalt der Nachricht übertragen und können beispielsweise aus Name-Wert-Paaren bestehen, die aus einem HTML-Formular stammen. Es können so neue Ressourcen auf dem Server entstehen oder bestehende modifiziert werden. POST-Daten werden im Allgemeinen nicht von Caches zwischengespeichert. Zusätzlich können bei dieser Art der Übermittlung auch Daten wie in der GET-Methode an den URI gehängt werden. (siehe unten) HEAD weist den Server an, die gleichen HTTP-Header wie bei GET, nicht jedoch den eigentlichen Dokumentinhalt (Body) zu senden. So kann zum Beispiel schnell die Gültigkeit einer Datei im Browsercache geprüft werden. PUT dient dazu eine Ressource (z. B. eine Datei) unter Angabe des Ziel-URIs auf einen Webserver hochzuladen. DELETE löscht die angegebene Ressource auf dem Server. Heute ist das, ebenso wie PUT, kaum implementiert bzw. in der Standardkonfiguration von Webservern abgeschaltet, beides erlangt jedoch mit RESTful Web Services und der HTTP-Erweiterung WebDAV neue Bedeutung. TRACE liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist – sinnvoll für das Debugging von Verbindungen. OPTIONS liefert eine Liste der vom Server unterstützen Methoden und Features. CONNECT wird von Proxyservern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen. RFC 5789 definiert zusätzlich eine PATCH Methode um Ressourcen zu modifizieren, in Abgrenzung zur PUT Methode deren Intention der Upload der kompletten Ressource ist. RESTful Web Services verwenden die unterschiedlichen Request-Methoden zur Realisierung von Web-Services. Insbesondere werden dafür die HTTP-Request-Methoden GET, POST, PUT/PATCH und DELETE verwendet. WebDAV fügt folgende Methoden zu HTTP hinzu: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK Hypertext Transfer Protocol 17
Argumentübertragung Häufig will ein Nutzer Informationen an eine Website senden. Dazu stellt HTTP prinzipiell zwei Möglichkeiten zur Verfügung: HTTP-GET Die Daten sind Teil der URL und bleiben deshalb beim Speichern oder der Weitergabe des Links erhalten. HTTP-POST Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart im HTTP-Body, so dass sie in der URL nicht sichtbar sind. Die zu übertragenden Daten müssen ggf. URL-kodiert werden, d. h. reservierte Zeichen müssen mit „%
HTTP GET Hier werden die Parameter-Wertepaare durch das Zeichen ? in der URL eingeleitet. Oft wird diese Vorgehensweise gewählt, um eine Liste von Parametern zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage berücksichtigen soll. Häufig besteht diese Liste aus Wertepaaren, welche durch das &-Zeichen voneinander getrennt sind. Die jeweiligen Wertepaare sind in der Form Parametername=Parameterwert aufgebaut. Seltener wird das Zeichen ; zur Trennung von Einträgen der Liste benutzt.[3] Ein Beispiel: Auf der Startseite von Wikipedia wird in das Eingabefeld der Suche „Katzen“ eingegeben und auf die Schaltfläche „Artikel“ geklickt. Der Browser sendet folgende oder ähnliche Anfrage an den Server: GET /wiki/Spezial:Search?search=Katzen&go=Artikel HTTP/1.1 Host: de.wikipedia.org …
Dem Wikipedia-Server werden zwei Wertepaare übergeben:
Argument Wert
search Katzen
go Artikel
Diese Wertepaare werden in der Form Argument1=Wert1&Argument2=Wert2
mit vorangestelltem ? an die geforderte Seite angehängt. Dadurch „weiß“ der Server, dass der Nutzer den Artikel Katzen betrachten will. Der Server verarbeitet die Anfrage, sendet aber keine Datei, sondern leitet den Browser mit einem Location-Header zur richtigen Seite weiter, etwa mit: HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2006 15:12:44 GMT Location: http://de.wikipedia.org/wiki/Katzen …
Der Browser befolgt diese Anweisung und sendet aufgrund der neuen Informationen eine neue Anfrage, etwa: GET /wiki/Katzen HTTP/1.1 Host: de.wikipedia.org … Hypertext Transfer Protocol 18
Und der Server antwortet und gibt den Artikel Katzen aus, etwa: HTTP/1.0 200 OK Date: Fri, 13 Jan 2006 15:12:48 GMT Last-Modified: Tue, 10 Jan 2006 11:18:20 GMT Content-Language: de Content-Type: text/html; charset=utf-8
Die Katzen (Felidae) sind eine Familie aus der Ordnung der Raubtiere (Carnivora) innerhalb der Überfamilie der Katzenartigen (Feloidea). …
Der Datenteil ist meist länger, hier soll nur das Protokoll betrachtet werden.
HTTP POST Da sich die Daten nicht in der URL befinden, können per POST große Datenmengen, z. B. Bilder, übertragen werden. Im folgenden Beispiel wird wieder der Artikel Katzen angefordert, doch diesmal verwendet der Browser aufgrund eines modifizierten HTML-Codes (method="POST") eine POST-Anfrage. Die Variablen stehen dabei nicht in der URL, sondern gesondert im Body-Teil, etwa: POST /wiki/Spezial:Search HTTP/1.1 Host: de.wikipedia.org Content-Type: application/x-www-form-urlencoded Content-Length: 24
search=Katzen&go=Artikel
Auch das versteht der Server und antwortet wieder mit beispielsweise folgendem Text: HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2006 15:32:43 GMT Location: http://de.wikipedia.org/wiki/Katzen …
HTTP-Statuscodes → Hauptartikel: HTTP-Statuscode Jede HTTP-Anfrage wird vom Server mit einem HTTP-Statuscode beantwortet. Er gibt zum Beispiel Informationen darüber, ob die Anfrage erfolgreich bearbeitet wurde, oder teilt dem Client, also etwa dem Browser, im Fehlerfall mit, wo (z. B. Umleitung) bzw. wie (z. B. mit Authentifizierung) er die gewünschten Informationen (wenn möglich) erhalten kann. Hypertext Transfer Protocol 19
1xx Informationen
Die Bearbeitung der Anfrage dauert trotz der Rückmeldung noch an. Eine solche Zwischenantwort ist manchmal notwendig, da viele Clients nach einer bestimmten Zeitspanne (Timeout) automatisch annehmen, dass ein Fehler bei der Übertragung oder Verarbeitung der Anfrage aufgetreten ist, und mit einer Fehlermeldung abbrechen.
2xx Erfolgreiche Operation
Die Anfrage wurde bearbeitet und die Antwort wird an den Anfragesteller zurückgesendet.
3xx Umleitung
Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich. Das ist zum Beispiel der Fall, wenn eine Webseite vom Betreiber umgestaltet wurde, so dass sich eine gewünschte Datei nun an einem anderen Platz befindet. Mit der Antwort des Servers erfährt der Client im Location-Header, wo sich die Datei jetzt befindet.
4xx Client-Fehler
Bei der Bearbeitung der Anfrage ist ein Fehler aufgetreten, der im Verantwortungsbereich des Clients liegt. Ein 404 tritt beispielsweise ein, wenn ein Dokument angefragt wurde, das auf dem Server nicht existiert. Ein 403 weist den Client darauf hin, dass es ihm nicht erlaubt ist, das jeweilige Dokument abzurufen. Es kann sich zum Beispiel um ein vertrauliches oder nur per HTTPS zugängliches Dokument handeln.
5xx Server-Fehler
Es ist ein Fehler aufgetreten, dessen Ursache beim Server liegt. Zum Beispiel bedeutet 501, dass der Server nicht über die erforderlichen Funktionen (d. h. zum Beispiel Programme oder andere Dateien) verfügt, um die Anfrage zu bearbeiten.
Zusätzlich zum Statuscode enthält der Header der Server-Antwort eine Beschreibung des Fehlers in englischsprachigem Klartext. Zum Beispiel ist ein Fehler 404 an folgendem Header zu erkennen: HTTP/1.1 404 Not Found …
HTTP-Authentifizierung → Hauptartikel: HTTP-Authentifizierung Stellt der Webserver fest, dass für eine angeforderte Datei Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem Statuscode 401 Unauthorized und dem Header WWW-Authenticate. Dieser prüft, ob die Angaben vorliegen, oder präsentiert dem Anwender einen Dialog, in dem Name und Passwort HTTP-Authentifizierung einzutragen sind, und überträgt diese an den Server. Stimmen die Daten, wird die entsprechende Seite an den Browser gesendet. Es wird nach RFC 2617 unterschieden in:
Basic Authentication Die Basic Authentication ist die häufigste Art der HTTP-Authentifizierung. Der Webserver fordert eine Authentifizierung an, der Browser sucht daraufhin nach Benutzername/Passwort für diese Datei und fragt gegebenenfalls den Benutzer. Anschließend sendet er die Authentifizierung mit dem Authorization-Header in der Form Benutzername:Passwort Base64-codiert an den Server. Base64 bietet keinen kryptographischen Schutz, daher kann dieses Verfahren nur beim Einsatz von HTTPS als sicher angesehen werden. Digest Access Authentication Bei der Digest Access Authentication sendet der Server zusätzlich mit dem WWW-Authenticate-Header eine eigens erzeugte zufällige Zeichenfolge („nonce“). Der Browser berechnet den Hashcode der gesamten Daten (Benutzername, Passwort, erhaltener Zeichenfolge, HTTP-Methode und angeforderter URI) und sendet sie im Authorization-Header zusammen mit dem Benutzernamen und der zufälligen Zeichenfolge zurück an den Server, der diese mit der selbst berechneten Prüfsumme vergleicht. Ein Abhören der Kommunikation nützt Hypertext Transfer Protocol 20
hier einem Angreifer nichts, da sich durch die Verschlüsselung mit dem Hashcode die Daten nicht rekonstruieren lassen und für jede Anforderung anders lauten.
HTTP-Kompression Um die übertragene Datenmenge zu verringern, kann ein HTTP-Server seine Antworten komprimieren. Ein Client muss bei einer Anfrage mitteilen, welche Kompressionsverfahren er verarbeiten kann. Dazu dient der Header Accept-Encoding (etwa Accept-Encoding: gzip, deflate). Der Server kann dann die Antwort mit einem vom Client unterstützten Verfahren komprimieren und gibt im Header Content-Encoding das verwendete Kompressionsverfahren an. HTTP-Kompression spart vor allem bei textuellen Daten (HTML, CSS, Javascript) erhebliche Datenmengen, da sich diese gut komprimieren lassen. Bei bereits komprimierten Daten (etwa gängige Formate für Bilder, Audio und Video) ist die (erneute) Kompression nutzlos und wird daher üblicherweise nicht benutzt.
HTTP/2.0 Die IETF-Arbeitsgruppe HTTPbis beschäftigt sich mit der Überarbeitung von HTTP, das die Versionsnummer 2.0 tragen soll.[4] Google (SPDY) und Microsoft (HTTP Speed+Mobility)[5] haben jeweils eigene Vorschläge für HTTP/2.0 eingereicht und teilweise schon in ihren Browsern umgesetzt. Mit HTTP/2.0 soll die Übertragung beschleunigt und optimiert werden.[6] Dabei soll der neue Standard jedoch vollständig abwärtskompatibel zu HTTP/1.1 sein.
Spezifikationen • RFC 1945 (Hypertext Transfer Protocol – HTTP/1.0) • RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1)
Weblinks • Arbeitsgruppe der IETF zur Weiterentwicklung von HTTP [7] • HTTP-Anfrage- und Antwort-Header ansehen (englisch) [8] • HTTP-Header mehrerer URLs gleichzeitig ausgeben [9] • HttpTea, ein HTTP-Analysator (Freeware, englisch) [10] • Links zum Thema HTTP [11] im Open Directory Project • Microsofts ausführlicher Bericht zu http 2.0 (englisch) [12]
Einzelnachweise
[1] Tim Berners-Lee: The Original HTTP as defined in 1991 (http:/ / www. w3. org/ Protocols/ HTTP/ AsImplemented. html). In: www.w3.org, abgerufen am 13. November 2010.
[2] Hypertext Transfer Protocol - HTTP/1.1 (http:/ / tools. ietf. org/ html/ rfc2616). In: tools.ietf.org. [3] Ampersands in URI attribute values in der W3C-HTML 4.01 Specification, Appendix B: Performance, Implementation, and Design Notes
(http:/ / www. w3. org/ TR/ 1999/ REC-html401-19991224/ appendix/ notes. html#h-B. 2. 2)
[4] Golem.de: Mit SPDY auf dem Weg zu HTTP/2.0? (http:/ / www. golem. de/ 1201/ 89265. html)
[5] Microsofts Vorschlag zu HTTP 2.0 (http:/ / www. heise. de/ developer/ meldung/
Microsoft-bringt-eigenen-Vorschlag-fuer-HTTP-2-1479694. html) - abgerufen am 4. April 2012
[6] SPDY von Google (http:/ / www. heise. de/ ix/ meldung/ Googles-SPDY-soll-das-Web-beschleunigen-858994. html) - abgerufen am 4. April 2012
[7] http:/ / tools. ietf. org/ wg/ httpbis/
[8] http:/ / web-sniffer. net/
[9] http:/ / pc-intern. com/ http-header-bulkcheck. html
[10] http:/ / httptea. sourceforge. net/ Hypertext Transfer Protocol 21
[11] http:/ / www. dmoz. org/ World/ Deutsch/ Computer/ Netzwerk/ Protokolle_und_Dienste/ HTTP/
[12] http:/ / tools. ietf. org/ html/ draft-montenegro-httpbis-speed-mobility-01
Normdaten (Sachbegriff): GND: 4479982-2 (http:/ / d-nb. info/ gnd/ 4479982-2)
Hypertext
Ein Hypertext (amerikanisch-englische Aussprache [ˈhaɪpərˌtɛkst], zu deutsch Übertext) ist ein Text, der mit einer netzartigen Struktur von Objekten Informationen durch Querverweise (Hyperlinks) zwischen Hypertext-Knoten verknüpft. Hypertext wird in Auszeichnungssprachen geschrieben, die neben Format-Anweisungen auch Befehle für Hyperlinks enthalten; die bekannteste ist die Hypertext Markup Language (HTML) für Internetdokumente.
Nutzen Hypertexte bieten gegenüber der linearen Informationsdarstellung den Vorteil, komplexe Informationen vergleichsweise redundanzarm vermitteln zu können. Redundanzfreiheit spart nicht nur Speicher, sondern vereinfacht auch gleichzeitig die Wartung, da ein hinterlegter Wert zentral nur einmal geändert werden muss, um überall aktuell angezeigt zu werden, wo der Wert verknüpft ist. Die assoziative Struktur eines Hypertextes entspricht dabei eher der Funktionsweise des menschlichen Denkens als lineare Texte, da unser vernetztes Denken ähnlich abläuft, wie die Strukturen eines Hypertextes aufgebaut sind. Rolf Schulmeister verwendet dafür in diesem Zusammenhang den Verweis auf die „kognitive Plausibilitätshypothese“.[1]
Probleme Ein Problem beim Arbeiten mit Hypertext ist das gezielte Auffinden von Informationen. Während literate Menschen über Jahrhunderte in der Rezeption von linearen Texten geschult worden sind, begann man erst mit der zunehmenden Verbreitung des World Wide Web seit Mitte der 1990er Jahre den Umgang mit komplexen Hypertexten zu erlernen. Hilfsmittel wie Suchmaschinen und Suchfunktionen auf den Webseiten unterstützen den Nutzer. Ein weiteres Problem ist das Navigieren in Hypertexten, da vor allem in den Anfangsjahren häufig eine vom Autor vorgegebene Lesestruktur (z. B. Guided Tour) fehlte. Heute verfügen Hypertexte in der Regel über eine ausgefeilte Navigation. Als Folge eines Übermaßes an Querverweisen kann ein sogenannter Information Overload, die Überflutung mit ungeordneten Informationen und eine Desorientiertheit im weit verzweigten Netz von Texten (Lost in Hyperspace) entstehen. Die Lesegewohnheiten spielen hierbei eine wichtige Rolle. So haben online-affine Nutzer weniger Schwierigkeiten damit, das Lesen eines Textes zu unterbrechen, um einem Querverweis zu folgen. Problemlösungsansätze bieten virtuelle Mindmaps und Web-Ontologien. Erst in Ansätzen gelöst ist das Problem der Visualisierung von Hypertexten, also die grafisch aufbereitete Darstellung der typischerweise netzwerkförmigen und daher nicht hierarchisch präsentierbaren Struktur eines Hypertextes (siehe auch Hyperbolic Tree).
Geschichte und Entwicklung Hypertextuelle Strukturen sind seit Jahrhunderten bekannt; die im Aufschreibesystem der Neuzeit ausdifferenzierten Erschließungshilfen für lineare Texte wie Inhaltsverzeichnisse, Indizes, Querverweise und Fußnoten sowie jegliche Verweissysteme entsprechen funktional einem Hypertext. Eine fiktionale Erzählung, welche mit und für die Hypertextstruktur geschrieben wird, bezeichnet man als Hyperfiction; wird diese in Printform veröffentlicht, ist sie als Offline-Hyperfiction zu bezeichnen. Der Unterschied besteht darin, dass zum einen die Verweisziele nicht vor Ort präsent sein müssen, und zum anderen, dass das Verfolgen der Verweise nicht mechanisiert bzw. automatisiert ist. Als Vorläufer heutiger digitalisierter Hypertexte gilt daher beispielsweise Agostino Ramellis Bücherrad aus dem Hypertext 22
16. Jahrhundert und Roussels Lesemaschine, eine Art Wechselrad für Notizzettel, siehe Zettels Traum von Arno Schmidt. Literaturgeschichtlich prominent ist James Joyce’ vertracktes Werk Finnegans Wake, das an semantische Netze des Hypertext erinnert. Die erste bewusst als solche veröffentlichte Offline-Hyperfiction ist "Afternoon - A story" von Michael Joyce. Das moderne Hypertext-Konzept wurde von Vannevar Bush im Jahr 1945 in einem Artikel As We May Think im Journal The Atlantic Monthly erwähnt. Er sprach darin über ein zukünftiges System Memex (für Memory Extender), das das Wissen eines bestimmten Gebietes elektronisch aufbereitet leicht zugänglich darstellen kann. Diese Idee lag bereits der 1931 in den USA patentierten "Statistischen Maschine" von Emanuel Goldberg zugrunde.[2] Die Kernidee des Konzepts ist zum einen, dass das Verfolgen von Verweisen mit elektronischer Hilfe erleichtert wird und zum anderen, dass Bücher und Filme aus einer Bibliothek verfügbar gemacht und angezeigt werden können. Die Idee von Hypertext ist also von Anfang an mit alten Utopien von der „universellen Bibliothek“ verbunden. Daher ist es kein Zufall, dass der Herausgeber der Universalklassifikation Paul Otlet als frühester Pionier des Hypertext gilt und diese Universalsprache völkerverbindend einsetzen wollte. Er gilt nicht von ungefähr als Mitbegründer des Völkerbunds, aus dem die UNO hervorging. Ein Beispiel für ein hypertext-artiges Gedicht sind die Hunderttausend Milliarden Gedichte von Raymond Queneau (1961). Der Gesellschaftswissenschaftler Ted Nelson (Projekt Xanadu) prägte den Begriff „Hypertext“ im Jahr 1965. Eines der ersten Hypertextsysteme, das einer größeren Gruppe zugänglich war, war HyperCard der Firma Apple, das mit den Apple-Macintosh-Computern ausgeliefert wurde. Das heute am weitesten verbreitete Hypertext-System ist der Internet-Dienst World Wide Web (WWW), obwohl ihm einige wichtige Funktionen früherer Hypertextsysteme fehlen. So ist zum Beispiel das Problem der so genannten toten Links im WWW ungelöst, die nicht oder nicht mehr zum gewünschten Ziel führen. Auch die Einführung der Uniform Resource Identifiers (URIs) ist über die im Web gebräuchlichen URLs nur unvollständig erfüllt. Im Gegenzug erlaubt das WWW aber auch das Einbinden von nichtsprachlichen Datentypen wie Bildern, was als Hypermedia bezeichnet wird. Dadurch ist das WWW, obwohl auf Hypertext beruhend, streng genommen ein Hypermedia-System. Die Sprache, in der die Texte des World Wide Web beschrieben werden, heißt Hypertext Markup Language; Web-Dokumente werden von Webtextern und Webdesignern konzipiert und erstellt.
Typen von Hypertext-Systemen Bereits 1987 listete Jeffrey Conklin 18 verschiedene Hypertext Systeme auf. Man unterscheidet folgende vier Typen in Hypertext-Strukturen: • Systeme mit einfachen Einheiten, assoziativen Verknüpfungen und Browsing, • Systeme mit strukturierten Einheiten und typisierten Verknüpfungen. Die Navigation beruht auf dem Prinzip der direkten Manipulation. • Systeme mit strukturierten Einheiten und typisierten Verknüpfungen. Die Navigation beruht weitgehend auf dem Prinzip der direkten Manipulation, jedoch auch auf autorengestützten Pfaden. • Systeme auf der Grundlage von durch wissensbasierte Techniken strukturierten Einheiten und typisierten Verknüpfungen. Die Navigation ist nach dialogischen, kooperativen Prinzipien organisiert. Hypertext 23
Literatur • Stephan Porombka: Hypertext. Zur Kritik eines digitalen Mythos. Fink, München 2001, ISBN 3-7705-3573-1. • Peter Schnupp: Hypertext. Oldenbourg, München 1992, ISBN 3-486-21740-2. • Stefan Iske: Vernetztes Wissen. Hypertext-Strategien im Internet. Bertelsmann, Bielefeld 2002, ISBN 3-7639-0151-5. • George P. Landow: Hypertext 3.0. Critical Theory and New Media in a Era of Globalization. 3. Auflage. Johns Hopkins Univ. Press, Baltimore Md 2005, ISBN 0-8018-8257-5. • Jakob Krameritsch: Geschichte(n) im Netzwerk. Hypertext und dessen Potenziale für die Produktion, Repräsentation und Rezeption der historischen Erzählung. (Medien in der Wissenschaft. Bd 43). Waxmann, Münster 2007, ISBN 978-3-8309-1835-6. • Christiane Heibach: Literatur im Internet: Theorie und Praxis einer kooperativen Ästhetik. dissertation.de, Berlin 2000, ISBN 3-89825-126-8. (Heidelberg, Univ., Diss., 2000) • Rainer Kuhlen: Hypertext. Ein nicht-lineares Medium zwischen Buch und Wissensbank. Springer, Berlin 1991, ISBN 3-87940-509-3. • Rainer Hammwöhner: Offene Hypertextsysteme. Das Konstanzer Hypertextsystem (KHS) im wissenschaftlichen und technischen Kontext. Univ.-Verl. Konstanz, Konstanz 1997, ISBN 3-87940-608-1. • Thomas Fickert: Multimediales Lernen: Grundlagen–Konzepte–Technologien. Deutscher Universitäts-Verlag, Wiesbaden 1992, ISBN 3-8244-2036-8.
Weblinks • Bee-Hive the Hypertext/Hypermedia Literary Journal [3] • Cyberfiction [4] – Schweizer Magazin, das sich mit Hypertext/-fictions beschäftigt • Hypertext und Sprachwissenschaft - Dissertation von Oliver Huber [5] • 'Der Looppool' - Ein Hypertext Beispiel zum Hören, Lesen und Selbersteuern, Bas Böttcher [6]
Einzelnachweise [1] Rolf Schulmeister: Grundlagen hypermedialer Lernsysteme. Wessley, Bonn 1996, ISBN 3-89319-923-3, S. 257.
[2] Michael Buckland: Emanuel Goldberg, Electronic Document Retrieval, And Vannevar Bush's Memex. (http:/ / people. ischool. berkeley. edu/
~buckland/ goldbush. html) In: Journal of the American Society for Information Science. New York 43.1992, 4 (May), , S. 284-294.
[3] http:/ / beehive. temporalimage. com/ index. html
[4] http:/ / www. cyberfiction. ch/
[5] http:/ / edoc. ub. uni-muenchen. de/ archive/ 00000921/
[6] http:/ / www. looppool. de/
Normdaten (Sachbegriff): GND: 4239975-0 (http:/ / d-nb. info/ gnd/ 4239975-0) Uniform Resource Locator 24
Uniform Resource Locator
Ein Uniform Resource Locator (Abk. URL; englisch für einheitlicher Quellenanzeiger) identifiziert und lokalisiert eine Ressource wie z. B. eine Website über die zu verwendende Zugriffsmethode (z. B. das verwendete Netzwerkprotokoll wie HTTP oder FTP) und den Ort (engl. location) der Ressource in Computernetzwerken. Der aktuelle Stand ist als RFC 1738 publiziert. Die RFC-Spezifikationen sind industrielle Standards der Internet Foundation IETF [1]. URLs sind eine Unterart der generellen Identifikationsbezeichnung mittels Uniform Resource Identifiern (URIs). Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig synonym verwendet. Im allgemeinen Sprachgebrauch werden URLs auch als Internetadresse oder Webadresse bezeichnet,[2] wobei damit (der umgangssprachlich häufigen Gleichsetzung von Internet und WWW folgend) meist speziell URLs von Webseiten gemeint sind.
Aufbau Der grundsätzliche URL-Aufbau besteht aus einer die Zugriffsmethode festlegenden Schema-Bezeichnung (engl. scheme) und einem Schema-spezifischen Teil (scheme-specific-part), die durch einen Doppelpunkt getrennt sind:
wobei scheme oft, aber nicht zwingend gleich lautet wie das zugrundeliegende Netzwerkprotokoll (bei ftp oder http ist das z. B. der Fall, aber nicht bei mailto oder file). Mögliche URL-Elemente sind z. B. bei http:
scheme-specific-part → → → | | http://hans:[email protected]:80/demo/example.cgi?land=de&stadt=aa#geschichte | | | | | | | | | | | host | url-path query fragment | | password port | user scheme (hier gleich Netzwerkprotokoll)
bei mailto: mailto:[email protected] | | | E-Mail-Adresse gemäß RFC822) scheme (hier kein Netzwerkprotokoll)
bei news (in diesem Beispiel ist weder ein Netzwerkprotokoll noch eine Host-Adresse enthalten): news:alt.hypertext | | | Name der Newsgroup scheme
oder bei file:
file:///C:/foo/bar.txt | | Uniform Resource Locator 25
| Pfad zur Datei (lokal, d. h. im Dateisystem des Rechners, der die URL interpretiert) scheme
Streng genommen hat dieses Schema die Form file://
scheme Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll. Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten Netzwerkprotokoll, über das die Ressource lokalisiert werden kann. Beispiele sind HTTP, HTTPS oder FTP, aber auch mailto (zum Schreiben einer E-Mail) oder file (zum Zugriff auf lokale Dateien).
scheme-specific-part Je nach scheme sind unterschiedliche spezifische Angaben erforderlich und möglich. In den meisten Fällen beginnt er mit der Zeichenkette ://, jedoch ist bei manchen Varianten auch lediglich der Doppelpunkt definiert. Die folgenden Beispiele beziehen sich auf das HTTP-Protokoll.
user/password Falls benötigt, kann ein Login aus Benutzername (user) und Passwort (password) übermittelt werden. Diese werden, voneinander durch Doppelpunkt getrennt, dem Host mit einem trennenden At-Zeichen (@) vorangestellt. Auch wenn für dieses Beispiel das Protokoll HTTP gewählt wurde, ist die Angabe von Benutzername und Passwort als Teil der URL nicht Teil der HTTP-Spezifikation![5] Aktuelle Browser akzeptieren diese URL-Syntax zwar, fragen aber beim Benutzer nach, ob er sich wirklich mit den angegebenen Daten anmelden möchte. Der Internet Explorer 6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen. Mit einem Registry-Eintrag kann man sie zum gleichen Verhalten zwingen, wie es die Vorgänger bis Version 5.5 zeigen: Diese übernehmen die Anmeldedaten ungefragt und übergeben sie direkt an den Server. Bei einigen anderen Protokollen, etwa FTP, ist die Angabe der Benutzerdaten in der gezeigten Form dagegen völlig korrekt und durch die Standards abgedeckt.
host Die Host-Komponente wird in Form einer IPv4-Adresse in dezimaler Schreibweise durch Punkte getrennt, in Form einer IPv6-Adresse in hexadezimaler Schreibweise durch Doppelpunkte getrennt und in eckige Klammern gesetzt oder in Form eines FQDN notiert.[6]
Port Die Angabe des Ports erlaubt die Ansteuerung eines TCP/IP-Ports. Wird kein Port angegeben, so wird der Standard-Port des jeweiligen Protokolls verwendet – zum Beispiel bei HTTP 80, bei HTTPS 443 und bei FTP 21. Uniform Resource Locator 26
Url-path Der Pfad beschreibt eine bestimmte Ressource (diese kann sich beispielsweise mit der Verzeichnisstruktur des Zielsystems decken, also etwa eine Datei oder ein Verzeichnis) auf dem Server. Der Pfad kann auch leer sein. Ein leerer Pfad kann optional durch einen Slash ersetzt werden und ist zu diesem gleichbedeutend. Die Interpretation (Datei oder Verzeichnis; Textdatei liefern oder Skript ausführen) bleibt dem Server überlassen. Ein typisches Beispiel für die Interpretationsfreiheit ist das Verhalten bei der Anforderung des Pfades / durch einen Client: Je nach Einstellung liefert der Server etwa den Inhalt einer namentlich ausgezeichneten Datei (wie /index.html, /README, /HEADER), ohne dass dies für den anfragenden Client ersichtlich ist. Genauso kann der Server allerdings – je nach Protokoll – auch explizit zu dieser Ressource weiterleiten oder eine Verzeichnisauflistung ausgeben.
Query String → Hauptartikel: Query String Im Fall des HTTP kann nach dem eigentlichen Ressourcenanzeiger – getrennt durch ein Fragezeichen – ein Query String folgen.[7] Damit können zusätzliche Informationen übertragen werden, die server- oder clientseitig weiterverarbeitet werden können.
Fragment Nach einem Doppelkreuz kann ein Teil der Ressource referenziert werden (typischerweise ein Anker in einer HTML-Seite, zu dem dann automatisch heruntergescrollt wird: Die URL „http://example.com/dokument.html#absatz3“ würde im fiktiven Dokument den Anfang des dritten Absatzes zeigen.
Beispiele • ftp://hans:[email protected] FTP mit Benutzer und Passwort • http://de.wikipedia.org Webseite ohne Pfad (Aufruf der „Startseite“) • http://de.wikipedia.org/wiki/Uniform_Resource_Locator Webseite mit Pfad • mailto:[email protected] zum Schreiben einer E-Mail an die angegebene Mailadresse (öffnet den Standard-Mailclient mit einer neuen, leeren Mail, in der die TO-Adresse vorausgefüllt ist) • news:alt.hypertext Anzeige einer Usenet-Newsgruppe (generisch, ohne Angabe des Netzwerkprotokolls NNTP) • nntp:alt.hypertext Anzeige einer Usenet-Newsgruppe (mit Angabe des Netzwerkprotokolls NNTP) • telnet:example.org Start einer Telnet-Session • file:///C:/foo/bar.txt Zugriff auf eine lokale Datei Uniform Resource Locator 27
Sprachgebrauch Die Abkürzung URL wird im deutschen Sprachgebrauch häufig mit einem weiblichen Artikel, aber auch mit männlichem Artikel verwendet.[8] Die Wahl des Genus hängt davon ab, ob es in Anlehnung an die deutsche Übersetzung „die Adresse“ (feminin) gebildet wird oder mittels der Regel, dass Wörter auf „-or“ (hier „Locator“ oder „-identifikator“) oder „-er“ („-bezeichner“, „-lokalisierer“, „-anzeiger“) im Deutschen stets maskulin sind.[9]
URLs in Texten RFC 3986, Anhang C, empfiehlt, URIs (und damit auch URLs) in Texten • eigenständig auf einer Zeile, • mit doppelten Anführungsstrichen "http://example.com/" oder • mit spitzen Klammern
Relative URL Neben den bisher dargestellten „absoluten“ oder „vollständigen“ URL gibt es auch relative URL.[10] Sie sind nur innerhalb eines Kontextes gültig, von dem sie Eigenschaften „erben“. Ihnen fehlt die Ortsangabe im World Wide Web oder einem echten Intranet. Sie sind vor allem in der Gruppe http, https und ftp möglich, aber auch bei mailto. Das entspräche einer Telefonnummer ohne Vorwahl (des Landes, des Ortsnetzes).
Relative URL für http, https, ftp
Beginn Bedeutung Anmerkung Beispiel
// Gleiches Protokoll sinnvoll, um http: oder https: der momentanen //example.com/pfad/zu/datei Umgebung zu verwenden
/ Gleiche Domäne (host+port), /pfad/zu/datei „Wurzelverzeichnis“
# Gleiche Ressource Wirkung über Nebenwirkung #
#fragment Gleiche Ressource, Sprungmarke #knoten
nichts Gleiche Ressource
../ ein Pfad-Segment aufwärts Ein Server muss keine durch / gegliederte /pfad/zur/../zur/datei Pfad-Segmentierung unterstützen. ./relativer/pfad ./ gleiches Pfad-Segment sonstige
Relative URL werden oft eingesetzt, um eine Gruppe zusammengehörender Ressourcen wahlweise in einem lokalen Dateisystem oder an unterschiedlichen Orten in verschiedenen Netzwerk-Domänen unverändert abzulegen und aufeinander zu verlinken. Im Übrigen ist die Interpretation des Identifikators (Zeichenkette zwischen host+port und #) jedem Server freigestellt – zwar handhabt es die weitaus überwiegende Anzahl der Server und jede Standard-Software wie oben angegeben, jedoch können / genau wie ? % & nach eigenen Regeln ausgewertet werden. Bei mailto: wäre eine relative URL mailto:Nachbar (ohne @) – sie gilt nur im lokalen Netzwerk. Uniform Resource Locator 28
Geschichte
Name und Standardisierung In der Anfangszeit des WWW (ab Ende 1990) fand sich in der Dokumentation auf info.cern.ch zunächst keine dezidierte Bezeichnung für die Adressierung von Webseiten, das Thema wurde nur beschreibend als „W3 document address“, „W3 name“, „W3 address“ oder „Hypertext Name“ dokumentiert. Die damals spezifizierte (und in den ersten Webseiten verwendete) Gestalt der Adressierung entspricht aber schon der später als „URL“ standardisierten Form; im Standardisierungsprozess wurden zwar Änderungen erwogen, wegen der inzwischen schon fortgeschrittenen Verbreitung des WWW aber wieder verworfen.[11] Im Sommer 1992 versuchte Tim Berners-Lee beim IETF-Meeting in Boston eine Arbeitsgruppe ins Leben zu rufen, die den Zugriff auf Dokumente im Web standardisieren sollte. Er schlug als Namen Universal Document Identifier (UDI) vor, womit nach seiner Vorstellung ein allgemeiner Internet-Standard definiert werden sollte. Der Name wurde aber als zu „arrogant“ kritisiert, was vor allem am Wort „universal“ (engl für allgemeingültig, umfassend) lag. Statt dessen wurde von der Gruppe der bescheidenere Begriff „uniform“ (engl für einheitlich) vorgeschlagen. Weiters wurde „Document“ durch „Resource“ ersetzt, um zu unterstreichen, dass das Web mit anderen Informationssystemen integriert werden sollte. Die URI-Arbeitsgruppe kam schließlich zustande, wobei noch eine weitere Namensänderung für den zu definierenden Standard beschlossen wurde: „Identifier“ wurde durch „Locator“ ersetzt, um zu betonen, dass es sich bei Web-Adressen nicht um dauerhaft registrierte Adressen handelt.[12] Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste – noch informelle – Standardisierungsentwurf RFC 1630 erst im Juni 1994 von Berners-Lee vorgelegt.[13] Er nennt den von Berners-Lee favorisierten Namen „Universal Resource Identifiers“ im Titel und definiert bereits die Begriffe URI, URL und URN. Im Dezember 1994 wurde von der Gruppe in RFC 1738 der Standard für „Uniform Resource Locators (URL)“ veröffentlicht.
Bestandteile Berners-Lee entlehnte die einzelnen Bestandteile zum Teil bewusst aus bereits existierenden Systemen, um Webadressen neuen Anwendern möglichst unmittelbar vertraut resp. logisch erscheinen zu lassen: • Der Path-Teil (http://www.example.com/foo/bar/baz.html) zitiert direkt die Pfad-Syntax in UNIX-Dateisystemen. • Die mit einem Doppel-Schrägstrich eingeleitete Notation des Hosts stammt aus der Syntax des Netzwerk-Dateisystems von Apollo Domain/OS, in der Pfade auf entfernten Hosts nach dem Muster //example.com/foo/bar/… adressiert wurden. • Das mit einem Doppelkreuz markierte Fragment ist der in den USA üblichen Schreibweise für Apartment- und Suitenummern in Postadressen entlehnt: „12 Foo Avenue #34“ steht für „Foo Avenue Nr. 12, Apartment 34“; entsprechend bedeutet foo.html#bar „Teil (Abschnitt, Kapitel…) bar innerhalb des Dokuments foo.html“. Uniform Resource Locator 29
Literatur • Tim Berners-Lee, Mark Fischetti: Der Web-Report. Der Schöpfer des World Wide Webs über das grenzenlose Potential des Internets. Econ, München 1999 (Originaltitel: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web), ISBN 3-430-11468-3.
Weblinks • RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax • RFC 1738 – Uniform Resource Locators (URL) • RFC 1808 – Relative Uniform Resource Locators (veraltet, aktuell: RFC 3986)
Einzelnachweise
[1] http:/ / www. ietf. org [2] Duden – Deutsches Universalwörterbuch, 6. Auflage [3] RFC 1738 Uniform Resource Locators (URL); 3.10 FILES
[4] http:/ / en. wikipedia. org/ wiki/ File_URI_scheme#Browser_behaviour [5] RFC2616: Hypertext Transfer Protocol – HTTP/1.1, 3.2.2 http URL [6] RFC 1738 Uniform Resource Locators (URL); 3.1. Common Internet Scheme Syntax [7] RFC 1738 Uniform Resource Locators (URL); 3.3. HTTP
[8] Duden – Deutsches Universalwörterbuch, siehe auch Online-Suche auf duden.de (http:/ / www. duden. de/ suche/ ?suchwort=URL&
suchbereich=mixed& btnSearch. x=0& btnSearch. y=0)
[9] Antwort des Bertelsmann-Verlags auf Frage nach Genus von „URL“ (http:/ / www. korrekturen. de/ forum/ index. cgi/ read/ 70) [10] RFC 3986, Abschnitt 4.2 [11] Berners-Lee 1999, S.63 [12] Berners-Lee 1999, S.62 [13] Berners-Lee 1999, S.63 Clean URL 30
Clean URL
Ein Clean URL oder Pretty URL (deutsch etwa sauberer URL, hübscher URL) ist ein Uniform Resource Locator (URL), der lesbare Wörter anstelle von technischen Kürzeln oder Datenbank-IDs enthält. So sind im Pfad weder searchpart- oder query-Komponenten noch Dateinamenserweiterungen wie z. B. .html, .php oder andere Informationen zur verwendeten Servertechnik wie cgi-bin oder cgi enthalten. Anstelle werden lesbare und beschreibende Titel oder lexikografische Lemmas, Kalenderdaten meist der Erscheinung und auch die Sprache des Inhalts, meist abgekürzt nach ISO 639, im URL verwendet. Es können auch Mischungen aus beiden Methoden auftreten, indem die ID zwar behalten wird, aber lesbare Worte hinzugefügt werden. In diesem Fall ist die ID das entscheidende Merkmal des URLs und die Worte können verändert oder weggelassen werden. In der Praxis ist es in der Regel gewollt, dass sich URLs aus dem Webbrowser als Lesezeichen ablegen und zu einem beliebigen späteren Zeitpunkt wieder aufrufen lassen können. Sie sollen auch an Dritte weitergegeben werden und von diesen aufgerufen werden können und dieselbe Aktion auslösen bzw. denselben Zustand erzeugen (etwa eine Suche durchführen).
Beispiele Ein Beispiel für sowohl saubere als auch sprechende URLs ist Wikipedia, deren URLs nach folgendem Schema aufgebaut sind:
So sieht der URL für den Begriff Clean URL beispielsweise wie folgt aus http://de.wikipedia.org/wiki/Clean_URL
anstatt eines URLs, der Rückschlüsse zur Technik gestattet http://de.wikipedia.org/w/index.php?title=Clean_URL
oder eines URLs, der keinen Hinweis zum Inhalt gibt http://de.wikipedia.org/w/index.php?id=123
Technik Clean URLs lassen sich auf Webserver- und auf Webanwendungsebene umsetzen. Auf Webanwendungsebene muss jedoch auch der Webserver entsprechend konfiguriert sein.
Webserverebene Die meisten Webserver wie Apache HTTP Server oder nginx können „saubere” URLs mithilfe von .htaccess oder auch mit Rewrite-Engines realisieren. Diese Module erlauben es, Anfragen anhand vorher definierter Regeln mithilfe von regulären Ausdrücken intern umzuschreiben, beziehungsweise umzuinterpretieren. So könnte beispielsweise die Anfrage von foo/bar dasselbe Ergebnis erzielen, wie die Anfrage von /index.php?q=/foo/bar. Das CGI-Protokoll bietet eine weitere Technik, dabei sieht ein Skript aufgerufen als /index.php/foo/bar /foo/bar als PATH_INFO.[1] Clean URL 31
Webanwendungsebene Manche Web-Content-Management-Systeme beinhalten bereits passende Rewrite-Regeln, wodurch das Aktivieren dieser trivial ist.
Vorteile • Benutzer können die Relevanz von sprechenden URLs schneller bewerten (ein aussagekräftiger URL wird in der Regel eher angeklickt als ein kryptischer) • Benutzer können sich die URLs leichter merken (und ähnliche Dateiendungen wie html oder htm müssen nicht mehr geraten werden) • Externe Links und Lesezeichen auf eine Seite sind wesentlich länger gültig, da sie von internen Änderungen unabhängig sind • Bei der Suchmaschinen-Optimierung (dort auch sefURL für search engine friendly) werden im Suchmaschinenranking von Keywords neben dem Seiteninhalt auch Domain- und Dateinamen einzelner Seiten bewertet
Quellen
[1] http:/ / tools. ietf. org/ html/ rfc3875#section-4. 1. 5
Weblinks
• Tim Berners-Lee: Cool URIs don't change. (http:/ / www. w3. org/ Provider/ Style/ URI) World Wide Web Consortium, 1998, abgerufen am 10. April 2013 (englisch).
• Short URLs Manual: Short URL Short URLs. (http:/ / www. mediawiki. org/ wiki/ Manual:Short_URL) In: MediaWiki. Abgerufen am 10. April 2013 (englisch).
• Andreas Bonini: URLs are for People, not Computers. (http:/ / www. not-implemented. com/
urls-are-for-people-not-computers/ ) In: Not Implemented. 05-04-2013, abgerufen am 9. April 2013 (englisch). Quelle(n) und Bearbeiter des/der Artikel(s) 32
Quelle(n) und Bearbeiter des/der Artikel(s)
World Wide Web Quelle: http://de.wikipedia.org/w/index.php?oldid=123867858 Bearbeiter: $traight-$hoota, .84.150.203.194, .rhavin, 2001:638:807:20D:F1FB:24D0:89F6:CC82, A.Savin, A11158, AWak3N, Ahellwig, Aka, Akkakk, Alauda, Alnilam, Andreas Buthmann, Andrsvoss, Andy01q, Armin P., Avoided, BD, Baumfreund-FFM, Ben-Zin, Binningench1, Binter, Björn Bornhöft, Boatideas, Bordor, BosonD, Brion VIBBER, Buckie, Bürger-falk, C-Lover, C-M, Cfaerber, Chaddy, Chricho, Chris.aw, Christian List, Complex, Conversion script, Cyper, Cú Faoil, D, DaB., Dachris, Daniel 1992, Der Messer, Der.Traeumer, DerHexer, Diba, Dinki97, Doc z, Doc.Heintz, Dodo von den Bergen, Dominic Z., Don Leut, Duczmal, Dundak, Dvd-junkie, Eehmke, Eike sauer, Elwood j blues, Elya, Emkaer, Engie, FBE2005, Fabian7351, Fanatickson, FelixBlumstrauß, FelixReimann, Finex, Fire, Fish-guts, Flashtech123, Florian Adler, Fomafix, Fozloki, FreeGroup, Fritz, FritzG, Färber, Gabbahead., Garnichtsoeinfach, Gerd Fahrenhorst, Gettler23, Guandalug, Guety, H-j, H.Albatros, HaThoRator, HaeB, Halbarath, Hammacool, HdEATH, Head, Hendrik Brummermann, Hephaion, Herr von Quack und zu Bornhöft, Hfastedge, Horst Gräbner, Howwi, Hubertl, Hybridbus, Hydro, Ich, Inkowik, InterceptorIII, Iste Praetor, Itti, JD, JGalt, JHo, JakobVoss, Jan Giesen, Jennifer-Love-Hewitt-Fan, Jens Meißner, JensBaitinger, Jivee Blau, Jobu0101, Joli Tambour, JotW, Joystick, Jpp, Jsson, JuergenL, KINO997, Kaffeefan, Kaisersoft, Karl-Henner, Katharina, Kedmanee, Kgfleischmann, Kh555, Kku, Knoerz, Kreuzschnabel, Kronf, Kurt Jansson, LKD, Laudrin, Lehmi, Leseratte, Liebeskind, Liquidat, Logograph, LosHawlos, Lukas²³, MAK, Magnus, MainFrame, Malte Hangsleben, MalteAhrens, MarioS, MarkusHagenlocher, Martin Bahmann, Martin Wantke, Mc-404, Metoc, Mguenther, Michael Micklei, MichaelDiederich, Michail der Trunkene, Mijozi, Mikered, Mikl, MilesTeg, Mnh, Molily, Mons Maenalus, Mravinszky, Mue, Musik-chris, NACHTFALKEueberBERLIN, Nachbarnebenan, Nb, Nicolas G., Nightfly85, Nightflyer, Nikkis, Ninjamask, Nocturne, Nolispanmo, NordNordWest, Normalo, Nuhaa, O.Koslowski, Olei, Ot, OttoK, Ottomanisch, PaterMcFly, Paul Ebermann, PeeCee, Pendulin, Perlentaucher, Peter200, Pfieffer Latsch, Phrood, Pittimann, Pygmalion, RalfZosel, Randolph33, Raphael Kirchner, Reclus, Regi51, Remi, Ri st, Roo1812, S.lukas, SCPS, STBR, Sabria, Sadako, Schaengel89, Schlurcher, Schuhpuppe, Se4598, Sebastian.Dietrich, Seewolf, Semper, Siebrand, Sinn, Smart, Smial, Sokonbud, Solaris3, Solphusion, Southpark, Stefan64, Steffen, Steindy, Stern, Steschke, Suit, Syntronica, TMg, Timk70, Timo Baumann, Tobi B., Togs, TomK32, Toytoy, Trustable, Tschax, Tsor, Tsui, Tuxman, Tönjes, Uhr, Ulrich.fuchs, Uwe W., V.R.S., VanGore, Verbund, Vodimivado, Volunteer, WAH, Webkart, Wiegels, WikiNick, Wissenschaffer, Wittkowsky, Wkrautter, Wnme, Wolfgang Kopp, XXShizZo-AXx, XenonX3, Xqt, YMS, YourEyesOnly, Zahnstein, Zbik, Zellreder, Zemenespuu, Zenit, Zeno Gantner, Zulu55, pD9503B16.dip.t-dialin.net, 440 anonyme Bearbeitungen
Website Quelle: http://de.wikipedia.org/w/index.php?oldid=123470211 Bearbeiter: 111Alleskönner, A Ruprecht, Abubiju, Actionsponge, Aka, Alnilam, An-d, AndreasPraefcke, Anton-Josef, Arne List, Avoided, Azdak, Bdk, Benatrevqre, Benji, Bernard Ladenthin, Bitsandbytes, Bling Bling, Braveheart, C-M, ChrisHamburg, Cjesch, Cologinux, Complex, Corrigo, Crux, Cyper, D, DF5GO, Dachris, Daniel 1992, Dealerofsalvation, Delpino, Der.Traeumer, DerHexer, Diba, Diddi, Digital Nerd, Dirk Schneider, Dominic Z., Drcrusher, Duesentrieb, Dunadan, El., Elya, FBE2005, Fab, FalconL, Felistoria, Felix Stember, Flominator, Fritz, FutureCrash, GDK, GFJ, GNosis, Gail, Gebu, Geist, der stets verneint, Gleiberg, Gnu1742, Gonzo.Lubitsch, Gross bellmann, Guido Watermann, Günter W, H2m23, HAL Neuntausend, Hagbard, Hauner, Heckp, Horst Gräbner, Howwi, InaktiverBenutzer12345, Itu, J. 'mach' wust, JD, JakobVoss, Jivee Blau, Jkbw, Jogo.obb, Jonnyb74, JuergenL, Ka38ti0b, KaPe, Kam Solusar, Karl-Henner, Katharina, Kevin L., Kmhkmh, Kraftprotz, Kristjan, Kungfuman, LKD, Laila62, Larry wall, LarsKasper, Liberaler Humanist, LogoX, LosHawlos, Lustiger seth, Lycopithecus, MFM, MSk, Maikel, Malki1211, Mannerheim, Marcoscramer, Marsupium, Martinwilke1980, Media lib, Melancholie, Memnon335bc, Memset, Metaxa, Moinchen, Molily, Mps, Muetob, Musik-chris, Musikhörer, Myrios, Nd, NeaNita, Ned, Neun-x, Nicolas G., Odder, Onkel Sam, Ot, Otto Knell, Otv2007, Oxymoron83, Pajz, Pendulin, Peter200, PhChAK, Philipd, Pietz, Pittimann, Pjacobi, Polarlys, Pressi 89, Prof-Schmidt, Quintero, Raymond, Rayukk, Reconnect, Reinhard Kraasch, Reinhardfels, Remi, RolandIllig, RolandS, Rolf H., RonMeier, Ronald M. F., Rudolfox, S.K., Saltose, Saxo, Schweigerl, Sdr3, Seewolf, Sinn, Sinuspi, Slick, Speck-Made, Spuk968, Srbauer, StYxXx, Stefan Kühn, Stern, Suit, SunSpiele, T H, Tambora, The real Marcoman, TheK, Theredmonkey, Thorbjoern, Tilo, Tim Sperber, Tobnu, Togs, Toxilly, Trustable, Tullius, Tzeh, Tönjes, Uncopy, Usquam, Ute Erb, Uurur, W!B:, WAH, WernerPopken, Westiandi, Wiegels, WikiMax, WikiNick, WinfriedSchneider, WissensDürster, Wolfgang1018, Wurblzap, Xjs, YMS, YourEyesOnly, Zahnradzacken, Zenit, Zeno Gantner, °, 209 anonyme Bearbeitungen
Representational State Transfer Quelle: http://de.wikipedia.org/w/index.php?oldid=123140343 Bearbeiter: 08-15, 1000 Freunde, 2001:638:708:30DA:81F0:9583:259:8628, 2A00:E68:0:86:95FC:6818:4A2F:8C6D, 2A02:568:122:20:141A:355A:AD60:153B, A11158, ABrocke, AWendt, Aka, Alephone, Altkatholik62, AndreasSchreiber, André Huf, Beders, Bernard Ladenthin, Bernd vdB, Caritter, Cebus, Chiccodoro, Chrisg, ChristophDemmer, Daniel5Ko, DasBee, Dummschnigger, Ecki, Edoe, Eljo, Erwin E aus U, Flash1984, Florian Sening, GFJ, GGShinobi, Gunnar.scherf, Harry2o, Havelbaude, Hendrikn, HenrikGebauer, J.Ammon, Javaprog, Jogep, Jokannes, Joscha Feth, Jpp, Kai-Hendrik, Krd, L.m.k, Lars Kanis, Legshot, Lofor, Ma-Lik, Madeleine Brinvilliers, Marcus Kasner, MartinSteinicke, MauriceKA, Mef.ellingen, Momolin, MovGP0, Muck31, Naninanii, Nebu777, Nolispanmo, Ocrho, Panky9, Paramaeleon, Rloewe, SaidMS, Sebastian.Dietrich, Shepard, Smial, TheIgel69, Till.niermann, Trooper, Trustable, UUUU, Uncopy, Uwe Keim, VanGore, Wiegels, WiseWoman, Wondigoma, Zuphilip, 106 anonyme Bearbeitungen
Hypertext Transfer Protocol Quelle: http://de.wikipedia.org/w/index.php?oldid=123575825 Bearbeiter: 2402:1800:4000:1:3158:2BC1:A1B7:6D5C, A11158, Achim Raschka, AchimP, Ajv39, Aka, Alauda, Alexffm, An-d, Andre Engels, Andreas.traber, Armin P., Atz, BJ Axel, Balû, Ben-Zin, Benji, Bernard Ladenthin, Bernd vdB, Between the lines, Blah, C-Lover, Caulfield, Chd, Cherubino, Chri.koch, ChrisHamburg, Clemensfranz, Closett, Coldojeroldo, Complex, Conversion script, Cpcgm, Crazy1880, Cy Phex, Cyper, D, D235, DWay, DasBee, DataGhost, Der Messer, Der Wolf im Wald, Der.Traeumer, DerGraueWolf, DerHexer, Diba, Dienmatt, Dipede, Dominic Z., Ebertplatz, Echoray, El Fahno, Elvaube, Emkaer, Engie, Entlinkt, Euphoriceyes, ExIP, FBE2005, Fabian Bieker, Felino, Filzstift, Fit, Flominator, Florian Adler, Fomafix, Fubar, GFJ, GNosis, Gfis, GianVella, Gidoca, Goliu, Hansele, Harmey, He3nry, Head, Henryk Plötz, Hgulf, Hornisse, Horst Gräbner, Howwi, Hubertl, Hubi, ICE21, IGEL, Illik, Itti, JeeAge, Jivee Blau, Jobu0101, Joha.ma, Jpp, JuergenL, JörnB, KL47, Kalurak, Klever, Klxtctc, Knoerz, Krawi, Krd, Kroimon, Kubrick, Kurt Jansson, Leider, Lex parsimoniae, LudiKalell, Lukas²³, Lustiger seth, M.gissing, MFM, Mannerheim, Marian.sigler, MarianSigler, Marius.spix, Markus23, MarkusHagenlocher, Martin-vogel, Matthäus Wander, Mausganymed, Merlin G., Merlissimo, Metzi3, Mijozi, Mkleine, Mnh, Molily, Momomu, Mwka, Netspy, NeuerName2010, Nocturne, Oceancetaceen, Ocrho, Oxymoron83, PM3, Pajz, Parbit, Paul Ebermann, Peace656, PeeCee, Pendulin, PerfektesChaos, Peter200, Philipp Gruber, Philipp Wetzlar, Phobie, Pit, Pittimann, Pkn, Pm, Polluks, R1cky, Ralf5000, Rdb, Reclus, Rischmueller, Romanm, SDQ2, STBR, Sae1962, Schlesinger, Schnuffi72, Schoschi, SchwarzerKrauser, Schwarzweiß, Scooter, Se4598, Sebastian.Dietrich, Seewolf, Seth Cohen, ShithappensbyTuE, SimpleUpload.de, Sinn, Skyman gozilla, Sleske, Sovok, Speck-Made, Spuk968, Stange, Staro1, Stefan Majewsky, Stefan506, StefanLinke, Steffen, Steschke, Stw, Suit, TheIgel69, TheK, TheReincarnator, Thoken, Till.niermann, Timk70, Tobi B., Tobnu, Togs, TomK32, Tomalak, Tomsan69, TorstenNetzel, Traute Meyer, Travin, Trigonomie, Ttbya, Typokorrektör, Tönjes, Ulrich.fuchs, User-name, VanGore, Vierte Welle, Vren, WAH, Warp, Wikihelp, Wikimensch, Wolfgang H., Wondigoma, Wurmkraut, XTaran, YMS, YourEyesOnly, YvonneM, Zahnradzacken, Zuse, 341 anonyme Bearbeitungen
Hypertext Quelle: http://de.wikipedia.org/w/index.php?oldid=121327895 Bearbeiter: 0967532R, A.Savin, Achim Raschka, Acky69, Agramonte, Aka, AndreasPraefcke, Androl, Andrsvoss, Anpre91, Apulix, Asb, Axel Kittenberger, Baird's Tapir, Balbor T'han, Bbommel, Ben-Zin, Bernd vdB, Chaddy, Cherubino, Christian List, ChristophDemmer, Conversion script, D, Dandelo, Dasidu, DerHexer, DerSchnüffler, Diba, Dominik Kuropka, Don Magnifico, Dr. Karl-Heinz Best, Dundak, Elya, Enyavar, Flo 1, Fritz, Gerbil, Groucho M, Guido Watermann, HaeB, Head, Heidas, Howwi, Hubertl, Hutzel-Hugo, Hyper text, Igelball, Infotopia, Itti, JakobVoss, Johnny2b0, Jperl, JuergenL, Kam Solusar, Karl-Henner, Knopfkind, Krawi, Kurt Jansson, Langec, Lars Trebing, Liberaler Humanist, Lirum Larum, Livani, Lustiger seth, Löschfix, Magnus Manske, Marcel083, Martin1978, Matthäus Wander, Mbdortmund, Mikue, Minotauros, Mnh, Molily, Mudd1, N23.4, Nol Aders, Nolispanmo, Nxxos, Ottomanisch, Partonopier, Pato-logic, PaulBommel, Pendulin, Peter200, Philipp Basler, Phrood, Pittimann, Qhx, Qunst, RalfZosel, Randolph33, Rolf Todesco, Rolf acker, RonMeier, STBR, Salocin, Schlesinger, Schorschski, Sechmet, Semper, Shamrock7, Shaun72, Sinn, Skriptor, Stefan64, Steffen, Taborsky, Tali, Tamas Szabo, ThT, ThePeritus, Thomas Tunsch, Thomassk, Tilo, Tim Pritlove, TomK32, Twickaner, Tönjes, Ulli Purwin, Ulm, VanGore, VerwaisterArtikel, Wb2000, Webkram, WiESi, Wikifantexter, WikipediaMaster, Wikitoni, Wiky, Wildtierreservat, WissensDürster, Yodokus, Zeno Gantner, Zenon, Zero Thrust, Ziko, Zumbo, p3E9D33A5.dip.t-dialin.net, 174 anonyme Bearbeitungen
Uniform Resource Locator Quelle: http://de.wikipedia.org/w/index.php?oldid=123102627 Bearbeiter: 80686, A.Savin, ASM, Abdull, Abe Lincoln, Adornix, Ahoerstemeier, Aka, Alexander Brock, Andreas Lippold, Aphex3K, Asb, Asoedler, Bapho, Baumanns, Benji, Bernd vdB, Bernhard Wallisch, BesondereUmstaende, Big-Endian, Björn Bornhöft, Björn König, Blah, Blaubahn, Blue Lou, Braungucke, Brombeer, C.Löser, Cactus26, Capaci34, Carioca, Caulfield, Ceving, Cfaerber, Chaddy, ChrisiPK, ChristianErtl, ChristianHujer, Church of emacs, Complex, DasBee, Ddxc, Defchris, Delband, Der Rabe Ralf, Der.Traeumer, DerGraueWolf, DerHexer, Derschueler, Diba, Dominic Z., Don Magnifico, Drachentoeter, Drahtloser, Edoe, Engelmacher, Engie, Enyavar, Enzyklopädix, Flash1984, Flo12, Fomafix, FriedrichR, Frodolf, GNosis, Geitost, Gnu1742, Gpf, Greenhouse-JPBerlin, Guandalug, H-stt, HaeB, Hardenacke, He3nry, Head, Heckp, Helfmann, HenHei, Henning Ihmels, Holgerjakobs, Hoo man, Horst Gräbner, Howwi, Hubertl, Inkowik, Itti, JAF, JRG, JakobVoss, Jergen, Jivee Blau, Jkbw, Joystick, Jpkoester1, Kabelsalat, Kam Solusar, Karl432, Katzenmeier, Kiwipedian, Kiwipferd, Koenjo, Krantnejie, Kubieziel, LKD, Lady Suppenhuhn, Lehmi, LogoX, Logograph, Lustiger seth, M.L, MFM, MFleischhacker, Magnummandel, MainFrame, Mannerheim, Martin-vogel, Matthäus Wander, MaxStrobel, Media lib, Michael2402, Micwil, Mkleine, Mnh, Mps, Mueck, Murkel, Nb, Nepenthes, Netspy, Nightfly85, Nightflyer, Nikkis, Nils Reichardt, Nolispanmo, Normalo, Norro, Nothere, O.Koslowski, Oms, Palica, ParaDox, PatrickD, PerfektesChaos, Perhelion, Peter Walt A., Peter200, PhilipErdös, Philipendula, PhoeniXYZ, Pietz, Pittimann, Pluralis, RacoonyRE, Raphael Kirchner, Rdb, Reeno, Regi51, Reinhard Kraasch, Rodeng, RokerHRO, Rr2000, S.K., STBR, Saethwr, Sbeyer, Schlesinger, Schniggendiller, Schwalbe, Scooter, Se4598, Seewolf, Seth Cohen, Sieobserver, Simified, Sinn, Sinuhe20, Sinuspi, Small Axe, Sol1, Spuk968, Staro1, Stefan64, Suit, Tafkas, ThePeritus, Till.niermann, TobiasHerp, TorPedo, Trancos, Trash:Pet, Trustable, Tschäfer, Tönjes, Ulfh, Ulfrie, Ulm, Uncopy, Uweschwoebel, Vigilius, Viki, WAH, Wickie37, Wikifeld, Windharp, Wise guy, Wnme, Wolfgang1018, Wonko42, X-Weinzar, XanonymusX, YMS, YourEyesOnly, Zahnstein, ^icewind^, 398 anonyme Bearbeitungen
Clean URL Quelle: http://de.wikipedia.org/w/index.php?oldid=122955409 Bearbeiter: .love.is.war., Aka, Bahnmoeller, Boshomi, Doc z, EldurLoki, Euku, GeorgR (de), Gerold Broser, Jobu0101, Kaster, Kissaki, MovGP0, Nfl, Nixred, Pilawa, S.A.L., Seth Cohen, Sprachpfleger, Staro1, TMg, Trustable, Ureinwohner, Ute Erb, VanGore, Wedderkop, 22 anonyme Bearbeitungen Quelle(n), Lizenz(en) und Autor(en) des Bildes 33
Quelle(n), Lizenz(en) und Autor(en) des Bildes
Datei:WWW logo by Robert Cailliau.svg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:WWW_logo_by_Robert_Cailliau.svg Lizenz: Public Domain Bearbeiter: Hell Pé (PNG version); Bibi Saint-Pol (SVG version) Datei:WorldWideWebAroundWikipedia.png Quelle: http://de.wikipedia.org/w/index.php?title=Datei:WorldWideWebAroundWikipedia.png Lizenz: GNU Free Documentation License Bearbeiter: User:Chris 73 Datei:Tim berners lee webserver.jpg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Tim_berners_lee_webserver.jpg Lizenz: GNU Free Documentation License Bearbeiter: Ahellwig, Lorra, Nerits, Regi51, 4 anonyme Bearbeitungen Datei:Tim Berners-Lee_CP.jpg Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Tim_Berners-Lee_CP.jpg Lizenz: Creative Commons Attribution 2.0 Bearbeiter: Silvio Tanaka Datei:Http_auth_iw_10.png Quelle: http://de.wikipedia.org/w/index.php?title=Datei:Http_auth_iw_10.png Lizenz: Public Domain Bearbeiter: Mozilla Foundation/Debian Lizenz 34
Lizenz
Wichtiger Hinweis zu den Lizenzen Die nachfolgenden Lizenzen bezieht sich auf den Artikeltext. Im Artikel gezeigte Bilder und Grafiken können unter einer anderen Lizenz stehen sowie von Autoren erstellt worden sein, die nicht in der Autorenliste erscheinen. Durch eine noch vorhandene technische Einschränkung werden die Lizenzinformationen für Bilder und Grafiken daher nicht angezeigt. An der Behebung dieser Einschränkung wird gearbeitet. Das PDF ist daher nur für den privaten Gebrauch bestimmt. Eine Weiterverbreitung kann eine Urheberrechtsverletzung bedeuten. Creative Commons Attribution-ShareAlike 3.0 Unported - Deed
Diese "Commons Deed" ist lediglich eine vereinfachte Zusammenfassung des rechtsverbindlichen Lizenzvertrages (http:/ / de. wikipedia. org/ wiki/ Wikipedia:Lizenzbestimmungen_Commons_Attribution-ShareAlike_3. 0_Unported) in allgemeinverständlicher Sprache. Sie dürfen: • das Werk bzw. den Inhalt vervielfältigen, verbreiten und öffentlich zugänglich machen • Abwandlungen und Bearbeitungen des Werkes bzw. Inhaltes anfertigen Zu den folgenden Bedingungen: • Namensnennung — Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. • Weitergabe unter gleichen Bedingungen — Wenn Sie das lizenzierte Werk bzw. den lizenzierten Inhalt bearbeiten, abwandeln oder in anderer Weise erkennbar als Grundlage für eigenes Schaffen verwenden, dürfen Sie die daraufhin neu entstandenen Werke bzw. Inhalte nur unter Verwendung von Lizenzbedingungen weitergeben, die mit denen dieses Lizenzvertrages identisch, vergleichbar oder kompatibel sind. Wobei gilt: • Verzichtserklärung — Jede der vorgenannten Bedingungen kann aufgehoben werden, sofern Sie die ausdrückliche Einwilligung des Rechteinhabers dazu erhalten. • Sonstige Rechte — Die Lizenz hat keinerlei Einfluss auf die folgenden Rechte: • Die gesetzlichen Schranken des Urheberrechts und sonstigen Befugnisse zur privaten Nutzung; • Das Urheberpersönlichkeitsrecht des Rechteinhabers; • Rechte anderer Personen, entweder am Lizenzgegenstand selber oder bezüglich seiner Verwendung, zum Beispiel Persönlichkeitsrechte abgebildeter Personen.
• Hinweis — Im Falle einer Verbreitung müssen Sie anderen alle Lizenzbedingungen mitteilen, die für dieses Werk gelten. Am einfachsten ist es, an entsprechender Stelle einen Link auf http:/ / creativecommons. org/ licenses/
by-sa/ 3. 0/ deed. de einzubinden.
Haftungsbeschränkung Die „Commons Deed“ ist kein Lizenzvertrag. Sie ist lediglich ein Referenztext, der den zugrundeliegenden Lizenzvertrag übersichtlich und in allgemeinverständlicher Sprache, aber auch stark vereinfacht wiedergibt. Die Deed selbst entfaltet keine juristische Wirkung und erscheint im eigentlichen Lizenzvertrag nicht.
GNU Free Documentation License Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: • A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. • B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. • C. State on the Title page the name of the publisher of the Modified Version, as the publisher. • D. Preserve all the copyright notices of the Document. • E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. • F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. • G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. • H. Include an unaltered copy of this License. • I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. • J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. • K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. • L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. • M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. • N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. • O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. Lizenz 35
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements". 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new
problems or concerns. See http:/ / www. gnu. org/ copyleft/ . Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.