Uniform Resource Locator

Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll.[4] Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten Netzwerkprotokoll, über das die Ressource lokalisiert werden kann. Beispiele sind:

• mit gleich lautendem Protokoll: http, https oder ftp
• mit anderem Protokoll: mailto[5] (zum Schreiben einer E-Mail) oder file[6] (zum Zugriff auf lokale Dateien).

Je nach Schema 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 Hypertext Transfer Protocol (HTTP).

Falls benötigt, können Login-Informationen aus Benutzername (user) und Kennwort (password) mit übermittelt werden.[7] 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 Kennwort als Teil des URLs nicht Teil der HTTP-Spezifikation![8] 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.

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.[9]

Die Angabe des Ports erlaubt die Ansteuerung eines TCP-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.[10]

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.[11] Der Pfad kann auch leer sein; dieser leere Pfad kann optional durch einen Schrägstrich (englisch Slash) ersetzt werden und ist zu diesem gleichbedeutend.

Traditionell stellt ein Pfad, der mit einem Slash abgeschlossen wird, ein Verzeichnis dar, während ein Pfad, der nicht mit einem Schrägstrich abgeschlossen ist, gewöhnlich eine „Datei“ kennzeichnet – also ein „Blatt“ am Ende eines Zweiges, während Verzeichnisse die möglichen Verzweigungen darstellen. Suchmaschinen behandeln beide Schreibweisen meist gleich. Da dies für Nutzer allerdings verwirrend sein kann, sollte unterschiedlicher Content auch in unterschiedlichen Pfaden abgelegt werden.[12]

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.

Im Fall des HTTP kann nach dem eigentlichen Ressourcenzeiger – getrennt durch ein Fragezeichen – ein Query-String folgen.[13] Damit können zusätzliche Informationen übertragen werden, die server- oder clientseitig weiterverarbeitet werden können.

Nach einem Doppelkreuz kann ein Teil der Ressource referenziert werden, typischerweise ein Anker in einer HTML-Seite, zu dem nach dem Aufrufen der Seite automatisch hinuntergescrollt wird:[14] Der URL http://example.com/dokument.html#absatz3 würde, in dem hier fiktiven Dokument, den Browser dazu veranlassen, zum Anfang des dritten Absatzes zu scrollen.

Für http(s):

      |--------------------------- Schema-spezifischer Teil -----------------------------|
      |                                                                                  |
https://maxmuster:geheim@www.example.com:8080/documentation/index.html?p1=A&p2=B#ressource
\___/   \_______/ \____/ \_____________/ \__/\_______________________/ \_______/ \_______/
  |         |       |           |         |              |                 |         |
Schema¹ Benutzer Kennwort      Host      Port           Pfad             Query    Fragment

¹ hier gleich Netzwerkprotokoll

Für mailto:

mailto:max@example.org
\____/ \_____________/
   |          |
Schema²       |
        E-Mail-Adresse gemäß RFC 5322

² hier kein Netzwerkprotokoll

Für news (in diesem Beispiel ist weder ein Netzwerkprotokoll noch eine Host-Adresse enthalten):

 news:alt.hypertext
 \__/ \___________/
   |        |
Schema      |
       Name der Newsgroup

Für file:

 file:///verzeichnis/unterverzeichnis/datei
 \__/   \_________________________________/
   |                    |
Schema                  |
       Pfad zu einer lokalen Datei im Dateisystem des Rechners, der den URL interpretiert

Streng genommen hat das file-Schema die Form file://<host>/<path>, wobei aber der Host-Teil praktisch nicht verwendet wird, da das file-Schema mangels einer Möglichkeit, ein Netzwerkprotokoll für den Zugriff auf die Datei anzugeben, kaum sinnvoll über ein Netzwerk benutzt werden kann.[15] File-URLs werden beispielsweise in der Programmiersprache Java verwendet, um auf diese Weise auf lokale Dateien zuzugreifen.[16] Je nach Browser ist oftmals das Öffnen von file-Links nur nach spezieller clientseitiger Konfiguration oder unter Zuhilfenahme von AddOns etc. möglich.[17][18]

• ftp://max:muster@ftp.example.com … FTP mit Benutzer und Kennwort
• http://de.wikipedia.org … Website ohne Pfad (Aufruf der Startseite)
• http://de.wikipedia.org/wiki/Uniform_Resource_Locator … Website mit Pfad
• https://de.wikipedia.org … wie Aufruf der Website ohne Pfadangabe, allerdings mit dem verschlüsselten Hypertext Transfer Protocol Secure
• mailto:hans@example.org … zum Schreiben einer E-Mail an die angegebene Mailadresse (öffnet den Standard-Mailclient mit einer neuen, leeren Nachricht, 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:///foo/bar.txt … Zugriff auf eine lokale Datei

In der Anfangszeit des WWW (ab Ende 1990) fand sich in der Dokumentation auf info.cern.ch zunächst keine dedizierte Bezeichnung für die Adressierung von Webseiten, das Thema wurde nur beschreibend als „W3 document address“, „W3 name“, „W3 address“ oder „Hypertext Name“ dokumentiert.[26][27][28] 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.[27][29]

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 (englisch für „allgemeingültig“, „umfassend“) lag. Stattdessen wurde von der Gruppe der bescheidenere Begriff uniform (englisch für „einheitlich“) vorgeschlagen. Außerdem 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.[30]

Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste – noch informelle – Standardisierungsentwurf RFC 1630[31] erst im Juni 1994 von Berners-Lee vorgelegt.[29] 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 mit RFC 1738[1] der Standard mit dem Titel „Uniform Resource Locators (URL)“ veröffentlicht.

Berners-Lee entlehnte die einzelnen Bestandteile zum Teil bewusst von bereits existierenden Systemen, um Webadressen neuen Anwendern möglichst unmittelbar vertraut respektive logisch erscheinen zu lassen:[32]

• Der Pfad (http://www.example.com/verzeichnis/unterverzeichnis/datei.html) zitiert direkt die Pfad-Syntax in UNIX-Dateisystemen.[32]
• 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/verzeichnis/unterverzeichnis/… adressiert wurden.[32]
• 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 datei.html#ressource Teil (Abschnitt, Kapitel …) ressource innerhalb des Dokuments datei.html.[32]