Uniform Resource Locator: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''topic''' - Kurzbeschreibung
== Beschreibung ==
== Beschreibung ==
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Links ====
===== Weblinks =====
= TMP =
[[File:url01.png|mini|400px]]
[[File:url01.png|mini|400px]]


Ein '''Uniform Resource Locator''' (Abk. '''URL'''; {{enS}} für ''einheitlicher [[Ressource#Informatik|Ressourcenzeiger]]'') identifiziert und lokalisiert eine Ressource, beispielsweise eine [[Webseite]], über die zu verwendende Zugriffsmethode (zum Beispiel das verwendete [[Netzwerkprotokoll]] wie [[Hypertext Transfer Protocol|HTTP]] oder [[File Transfer Protocol|FTP]]) und den Ort (engl. {{lang|en|''location''}}) der Ressource in [[Rechnernetz|Computernetzwerken]].  
Ein '''Uniform Resource Locator''' (Abk. '''URL'''; {{enS}} für ''einheitlicher [[Ressource#Informatik|Ressourcenzeiger]]'') identifiziert und lokalisiert eine Ressource, beispielsweise eine [[Webseite]], über die zu verwendende Zugriffsmethode (zum Beispiel das verwendete [[Netzwerkprotokoll]] wie [[Hypertext Transfer Protocol|HTTP]] oder [[File Transfer Protocol|FTP]]) und den Ort (engl. {{lang|en|''location''}}) der Ressource in [[Rechnernetz|Computernetzwerken]].
* Der ursprüngliche Standard wurde im Dezember 1994 als RFC 1738 publiziert, er ist inzwischen durch die Veröffentlichung mehrerer anderer [[Request for Comments|RFCs]] obsolet.  
* Der ursprüngliche Standard wurde im Dezember 1994 als RFC 1738 publiziert, er ist inzwischen durch die Veröffentlichung mehrerer anderer [[Request for Comments|RFCs]] obsolet.
* Die aktuellen RFCs sind (Stand 2023):
* Die aktuellen RFCs sind (Stand 2023):


Zeile 40: Zeile 31:
|}
|}


URLs sind eine Unterart der generellen Identifikationsbezeichnung mittels [[Uniform Resource Identifier]]n (URIs).  
URLs sind eine Unterart der generellen Identifikationsbezeichnung mittels [[Uniform Resource Identifier]]n (URIs).
* Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig [[Synonymie|synonym]] verwendet.  
* Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig [[Synonymie|synonym]] verwendet.
* Im allgemeinen Sprachgebrauch werden URLs auch als '''Internetadresse''' oder '''Webadresse''' bezeichnet,<ref>Duden – ''Deutsches Universalwörterbuch.'' 6. Auflage.</ref> wobei damit (der umgangssprachlich häufigen Gleichsetzung von [[Internet]] und [[World Wide Web|WWW]]<ref>{{Internetquelle |url=http://www.news.de/medien/855030425/internet-und-world-wide-web-der-unterschied/1/ |titel=Internet und World Wide Web – der Unterschied |hrsg=News.de |datum=2009-10-29 |abruf=2010-12-11}}</ref> folgend) meist speziell URLs von [[Webseite]]n gemeint sind.
* Im allgemeinen Sprachgebrauch werden URLs auch als '''Internetadresse''' oder '''Webadresse''' bezeichnet,<ref>Duden – ''Deutsches Universalwörterbuch.'' 6. Auflage.</ref> wobei damit (der umgangssprachlich häufigen Gleichsetzung von [[Internet]] und [[World Wide Web|WWW]]<ref>{{Internetquelle |url=http://www.news.de/medien/855030425/internet-und-world-wide-web-der-unterschied/1/ |titel=Internet und World Wide Web – der Unterschied |hrsg=News.de |datum=2009-10-29 |abruf=2010-12-11}}</ref> folgend) meist speziell URLs von [[Webseite]]n gemeint sind.


Zeile 49: Zeile 40:


=== Schema ''(scheme)'' ===
=== Schema ''(scheme)'' ===
Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll.<ref name="rfc3986_3_1" /> Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten [[Netzwerkprotokoll]], über das die Ressource lokalisiert werden kann.  
Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll.<ref name="rfc3986_3_1" /> Ist meistens, aber nicht zwingend gleichlautend mit dem verwendeten [[Netzwerkprotokoll]], über das die Ressource lokalisiert werden kann.
* Beispiele sind:
* Beispiele sind:


Zeile 56: Zeile 47:


=== Schema-spezifischer Teil ''(scheme-specific part)'' ===
=== Schema-spezifischer Teil ''(scheme-specific part)'' ===
Je nach Schema sind unterschiedliche spezifische Angaben erforderlich und möglich.  
Je nach Schema sind unterschiedliche spezifische Angaben erforderlich und möglich.
* In den meisten Fällen beginnt er mit der Zeichenkette <code>//</code>, jedoch ist bei manchen Varianten auch lediglich der Doppelpunkt definiert.  
* In den meisten Fällen beginnt er mit der Zeichenkette <code>//</code>, jedoch ist bei manchen Varianten auch lediglich der Doppelpunkt definiert.
* Die folgenden Beispiele beziehen sich auf das Hypertext Transfer Protocol (HTTP).
* Die folgenden Beispiele beziehen sich auf das Hypertext Transfer Protocol (HTTP).


Zeile 63: Zeile 54:
Falls benötigt, können [[Login (Informationstechnik)|Login]]-Informationen aus [[Nickname|Benutzername]] ''(user)'' und [[Kennwort]] ''(password)'' mit übermittelt werden.<ref name="rfc3986_3_2_1" /> Diese werden, voneinander durch Doppelpunkt getrennt, dem Host mit einem trennenden At-Zeichen ([[@]]) vorangestellt.
Falls benötigt, können [[Login (Informationstechnik)|Login]]-Informationen aus [[Nickname|Benutzername]] ''(user)'' und [[Kennwort]] ''(password)'' mit übermittelt werden.<ref name="rfc3986_3_2_1" /> Diese werden, voneinander durch Doppelpunkt getrennt, dem Host mit einem trennenden At-Zeichen ([[@]]) vorangestellt.


Auch wenn für dieses Beispiel das Protokoll [[Hypertext Transfer Protocol|HTTP]] gewählt wurde, ist die Angabe von Benutzername und Kennwort als Teil des URLs ''nicht'' Teil der HTTP-Spezifikation!<ref>{{RFC-Internet |RFC=2616 |Titel=Hypertext Transfer Protocol |Datum= |Abschnitt=3.2.2 |Abschnittstitel=http URL|Standard=HTTP/1.1}}</ref> Aktuelle Browser akzeptieren diese URL-Syntax zwar, fragen aber beim Benutzer nach, ob er sich wirklich mit den angegebenen Daten anmelden möchte.  
Auch wenn für dieses Beispiel das Protokoll [[Hypertext Transfer Protocol|HTTP]] gewählt wurde, ist die Angabe von Benutzername und Kennwort als Teil des URLs ''nicht'' Teil der HTTP-Spezifikation!<ref>{{RFC-Internet |RFC=2616 |Titel=Hypertext Transfer Protocol |Datum= |Abschnitt=3.2.2 |Abschnittstitel=http URL|Standard=HTTP/1.1}}</ref> 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]]&nbsp;6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen.  
* Der [[Internet Explorer]]&nbsp;6 (ab Windows XP SP2) und neuere Versionen fallen hier aus dem Rahmen, indem sie diese URL-Syntax rundweg als fehlerhaft ablehnen.
* Mit einem [[Windows-Registrierungsdatenbank|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.
* Mit einem [[Windows-Registrierungsdatenbank|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.


Zeile 73: Zeile 64:


==== Port ====
==== Port ====
Die Angabe des [[Port (Protokoll)|Ports]] erlaubt die Ansteuerung eines [[Transmission Control Protocol|TCP]]-Ports.  
Die Angabe des [[Port (Protokoll)|Ports]] erlaubt die Ansteuerung eines [[Transmission Control Protocol|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.
* 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.


==== Pfad ''(Path)'' ====
==== Pfad ''(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 (Software)|Server]].<ref name="rfc3986_3_3" /> Der Pfad kann auch leer sein.  
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 (Software)|Server]].<ref name="rfc3986_3_3" /> Der Pfad kann auch leer sein.
* Ein leerer Pfad kann optional durch einen Slash ersetzt werden und ist zu diesem gleichbedeutend.
* Ein leerer Pfad kann optional durch einen Slash ersetzt werden und ist zu diesem gleichbedeutend.


Die Interpretation ([[Datei]] oder [[Verzeichnisstruktur|Verzeichnis]]; Textdatei liefern oder [[Skriptsprache|Skript]] ausführen) bleibt dem Server überlassen.  
Die Interpretation ([[Datei]] oder [[Verzeichnisstruktur|Verzeichnis]]; Textdatei liefern oder [[Skriptsprache|Skript]] ausführen) bleibt dem Server überlassen.
* Ein typisches Beispiel für die Interpretationsfreiheit ist das Verhalten bei der Anforderung des Pfades <code>/</code> durch einen Client: Je nach Einstellung liefert der Server etwa den Inhalt einer namentlich ausgezeichneten Datei (wie <code>/index.html</code>, <code>/README</code>, <code>/HEADER</code>), ohne dass dies für den anfragenden Client ersichtlich ist.  
* Ein typisches Beispiel für die Interpretationsfreiheit ist das Verhalten bei der Anforderung des Pfades <code>/</code> durch einen Client: Je nach Einstellung liefert der Server etwa den Inhalt einer namentlich ausgezeichneten Datei (wie <code>/index.html</code>, <code>/README</code>, <code>/HEADER</code>), ohne dass dies für den anfragenden Client ersichtlich ist.
* Genauso kann der Server allerdings –&nbsp;je nach Protokoll&nbsp;– auch explizit zu dieser Ressource weiterleiten oder eine Verzeichnisauflistung ausgeben.
* Genauso kann der Server allerdings –&nbsp;je nach Protokoll&nbsp;– auch explizit zu dieser Ressource weiterleiten oder eine Verzeichnisauflistung ausgeben.


Zeile 149: Zeile 140:


== Relative URLs ==
== Relative URLs ==
Neben den bisher dargestellten absoluten oder vollständigen URLs gibt es auch relative URLs. Sie sind nur innerhalb eines Kontextes gültig, von dem sie Eigenschaften erben.  
Neben den bisher dargestellten absoluten oder vollständigen URLs gibt es auch relative URLs. 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]].  
* 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.  
* Sie sind vor allem in der Gruppe http, https und ftp möglich, aber auch bei mailto.
* Das entspräche einer Telefonnummer ohne [[Telefonvorwahl|Vorwahl]] (des Landes, des [[Ortsnetz]]es).
* Das entspräche einer Telefonnummer ohne [[Telefonvorwahl|Vorwahl]] (des Landes, des [[Ortsnetz]]es).


Zeile 181: Zeile 172:
|}
|}


Relative URLs 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.  
Relative URLs 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 <code>host:port</code> und <code>#</code>) jedem Server freigestellt – zwar handhabt es die weitaus überwiegende Anzahl der Server und jede Standard-Software wie oben angegeben, jedoch können <code>/</code> genau wie <code>? %&nbsp;&</code> nach eigenen Regeln ausgewertet werden.
* Im Übrigen ist die Interpretation des Identifikators (Zeichenkette zwischen <code>host:port</code> und <code>#</code>) jedem Server freigestellt – zwar handhabt es die weitaus überwiegende Anzahl der Server und jede Standard-Software wie oben angegeben, jedoch können <code>/</code> genau wie <code>? %&nbsp;&</code> nach eigenen Regeln ausgewertet werden.


Zeile 213: Zeile 204:


== URLs und Suchmaschinen ==
== URLs und Suchmaschinen ==
Auch wenn URLs technisch komplex aufgebaut sein können, können schlecht gestaltete URLs die Auffindbarkeit von Inhalten durch Suchmaschinen behindern.  
Auch wenn URLs technisch komplex aufgebaut sein können, können schlecht gestaltete URLs die Auffindbarkeit von Inhalten durch Suchmaschinen behindern.
* Aus diesem Grund empfiehlt der Suchmaschinenbetreiber Google z.&nbsp;B.&nbsp;
* Aus diesem Grund empfiehlt der Suchmaschinenbetreiber Google z.&nbsp;B.&nbsp;
* den bedachten Einsatz von Parametern in URLs. Google hat auch die Begrifflichkeit der [[Canonical Link|kanonischen URL]] eingeführt.  
* den bedachten Einsatz von Parametern in URLs. Google hat auch die Begrifflichkeit der [[Canonical Link|kanonischen URL]] eingeführt.
* Eine kanonische URL ist demnach die URL der Seite, von der Google annimmt, dass sie die repräsentativste von mehrfachen Verweisen auf einer Website ist.  
* Eine kanonische URL ist demnach die URL der Seite, von der Google annimmt, dass sie die repräsentativste von mehrfachen Verweisen auf einer Website ist.
* Aus Sicht einer Suchmaschine sind z.&nbsp;B.&nbsp;
* Aus Sicht einer Suchmaschine sind z.&nbsp;B.&nbsp;
* die URL-Varianten <code>"<nowiki>http://www.example.com/</nowiki>" , "<nowiki>http://example.com/</nowiki>" , "<nowiki>https://www.example.com/</nowiki>" und "<nowiki>https://example.com/</nowiki>"</code>vier eigenständige Versionen, die – wenn keine kanonische URL definiert ist – zu "Duplicate-Content" und damit einer suboptimalen Sichtbarkeit führen können.
* die URL-Varianten <code>"<nowiki>http://www.example.com/</nowiki>" , "<nowiki>http://example.com/</nowiki>" , "<nowiki>https://www.example.com/</nowiki>" und "<nowiki>https://example.com/</nowiki>"</code>vier eigenständige Versionen, die – wenn keine kanonische URL definiert ist – zu "Duplicate-Content" und damit einer suboptimalen Sichtbarkeit führen können.
Zeile 227: Zeile 218:
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.<ref name="w3_naming_schemes" />
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.<ref name="w3_naming_schemes" />


Im Sommer 1992 versuchte [[Tim Berners-Lee]] beim [[Internet Engineering Task Force|IETF-Meeting]] in Boston eine Arbeitsgruppe ins Leben zu rufen, die den Zugriff auf Dokumente im Web standardisieren sollte.  
Im Sommer 1992 versuchte [[Tim Berners-Lee]] beim [[Internet Engineering Task Force|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.  
* 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.  
* Der Name wurde aber als zu „arrogant“ kritisiert, was vor allem am Wort ''universal'' (engl. für ''allgemeingültig'', ''umfassend'') lag.
* Stattdessen wurde von der Gruppe der bescheidenere Begriff ''uniform'' (engl. für ''einheitlich'') vorgeschlagen.  
* Stattdessen wurde von der Gruppe der bescheidenere Begriff ''uniform'' (engl. für ''einheitlich'') vorgeschlagen.
* Außerdem wurde „Document“ durch „Resource“ ersetzt, um zu unterstreichen, dass das Web mit anderen Informationssystemen integriert werden sollte.  
* 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.
* 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.


Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste –&nbsp;noch informelle&nbsp;– Standardisierungsentwurf RFC 1630 erst im Juni 1994 von Berners-Lee vorgelegt. Er nennt den von Berners-Lee favorisierten Namen „Universal Resource Identifiers“ im Titel und definiert bereits die Begriffe URI, URL und [[Uniform Resource Name|URN]].  
Aufgrund der konfliktreichen Arbeitsweise der Gruppe wurde der erste –&nbsp;noch informelle&nbsp;– Standardisierungsentwurf RFC 1630 erst im Juni 1994 von Berners-Lee vorgelegt. Er nennt den von Berners-Lee favorisierten Namen „Universal Resource Identifiers“ im Titel und definiert bereits die Begriffe URI, URL und [[Uniform Resource Name|URN]].
* Im Dezember 1994 wurde von der Gruppe mit RFC 1738 der Standard mit dem Titel „Uniform Resource Locators (URL)“ veröffentlicht.
* Im Dezember 1994 wurde von der Gruppe mit RFC 1738 der Standard mit dem Titel „Uniform Resource Locators (URL)“ veröffentlicht.


Zeile 241: Zeile 232:
* Der Pfad (<code><nowiki>http://www.example.com</nowiki>'''/verzeichnis/unterverzeichnis/datei.html'''</code>) zitiert direkt die Pfad-Syntax in [[Dateisystem#Hierarchische Dateisysteme|UNIX-Dateisystemen]].<ref name="tbl_faq" />
* Der Pfad (<code><nowiki>http://www.example.com</nowiki>'''/verzeichnis/unterverzeichnis/datei.html'''</code>) zitiert direkt die Pfad-Syntax in [[Dateisystem#Hierarchische Dateisysteme|UNIX-Dateisystemen]].<ref name="tbl_faq" />
* Die mit einem Doppel-Schrägstrich eingeleitete Notation des Hosts stammt aus der Syntax des [[Dateisystem#Netzwerkdateisysteme|Netzwerk-Dateisystems]] von [[Apollo Computer|Apollo Domain/OS]], in der Pfade auf entfernten Hosts nach dem Muster <code>'''//example.com'''/verzeichnis/unterverzeichnis/…</code> adressiert wurden.<ref name="tbl_faq" />
* Die mit einem Doppel-Schrägstrich eingeleitete Notation des Hosts stammt aus der Syntax des [[Dateisystem#Netzwerkdateisysteme|Netzwerk-Dateisystems]] von [[Apollo Computer|Apollo Domain/OS]], in der Pfade auf entfernten Hosts nach dem Muster <code>'''//example.com'''/verzeichnis/unterverzeichnis/…</code> adressiert wurden.<ref name="tbl_faq" />
* Das mit einem [[Doppelkreuz (Schriftzeichen)|Doppelkreuz]] markierte Fragment ist der in den [[Vereinigte Staaten|USA]] üblichen Schreibweise für [[Apartment]]- und [[Suite (Zimmerflucht)|Suitenummern]] in Postadressen entlehnt: ''12&nbsp;Foo&nbsp;Avenue&nbsp;#34'' steht für ''Foo Avenue Nr.&nbsp;12, Apartment 34''.  
* Das mit einem [[Doppelkreuz (Schriftzeichen)|Doppelkreuz]] markierte Fragment ist der in den [[Vereinigte Staaten|USA]] üblichen Schreibweise für [[Apartment]]- und [[Suite (Zimmerflucht)|Suitenummern]] in Postadressen entlehnt: ''12&nbsp;Foo&nbsp;Avenue&nbsp;#34'' steht für ''Foo Avenue Nr.&nbsp;12, Apartment 34''.
* Entsprechend bedeutet <code>datei.html'''#ressource'''</code> ''Teil (Abschnitt, Kapitel&nbsp;…) <code>ressource</code>'' innerhalb des Dokuments <code>datei.html</code>.<ref name="tbl_faq" />
* Entsprechend bedeutet <code>datei.html'''#ressource'''</code> ''Teil (Abschnitt, Kapitel&nbsp;…) <code>ressource</code>'' innerhalb des Dokuments <code>datei.html</code>.<ref name="tbl_faq" />


== Siehe auch ==
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
* [[Digital Object Identifier]]
* [[Digital Object Identifier]]
* [[Homographischer Angriff]]
* [[Homographischer Angriff]]
Zeile 255: Zeile 250:
* [[URL-Template]]
* [[URL-Template]]


== Weblinks ==
=== RFC ===
* {{RFC-Internet |RFC=3986 |Titel=Uniform Resource Identifier (URI): Generic Syntax |Datum=2005-01 |Updated=6874 |Obsoletes=2732 |Errata=1}}
* {{RFC-Internet |RFC=3986 |Titel=Uniform Resource Identifier (URI): Generic Syntax |Datum=2005-01 |Updated=6874 |Obsoletes=2732 |Errata=1}}
* {{RFC-Internet |Autor=T. Berners-Lee, L. Masinter, M. McCahill |RFC=1738 |Titel=Uniform Resource Locators (URL) |Datum=1994-12 |Updated=1808 |Errata=1}}
* {{RFC-Internet |Autor=T. Berners-Lee, L. Masinter, M. McCahill |RFC=1738 |Titel=Uniform Resource Locators (URL) |Datum=1994-12 |Updated=1808 |Errata=1}}
* {{RFC-Internet |Autor=R. Fielding |RFC=1808 |Titel=Relative Uniform Resource Locators |Datum=1995-06 |Kommentar=Wurde durch RFC 3986 obsolete}}
* {{RFC-Internet |Autor=R. Fielding |RFC=1808 |Titel=Relative Uniform Resource Locators |Datum=1995-06 |Kommentar=Wurde durch RFC 3986 obsolete}}
==== Links ====
===== Weblinks =====


[[Kategorie:Netzwerk/Adresse]]
[[Kategorie:Netzwerk/Adresse]]
</noinclude>
</noinclude>

Version vom 27. Januar 2024, 11:42 Uhr

topic - Kurzbeschreibung

Beschreibung

Ein Uniform Resource Locator (Abk. URL; für einheitlicher Ressourcenzeiger) identifiziert und lokalisiert eine Ressource, beispielsweise eine Webseite, über die zu verwendende Zugriffsmethode (zum Beispiel das verwendete Netzwerkprotokoll wie HTTP oder FTP) und den Ort (engl. Vorlage:Lang) der Ressource in Computernetzwerken.

  • Der ursprüngliche Standard wurde im Dezember 1994 als RFC 1738 publiziert, er ist inzwischen durch die Veröffentlichung mehrerer anderer RFCs obsolet.
  • Die aktuellen RFCs sind (Stand 2023):
Nummer Beschreibung
3986 Uniform Resource Identifier (URI): Generic Syntax
6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
8820 URI Design and Ownership
4248 The telnet URI Scheme
4266 The gopher URI Scheme
6068 The ‘mailto’ URI Scheme
6196 Moving mailserver: URI Scheme to Historic
6270 The ‘tn3270’ URI Scheme
8089 The "file" URI Scheme

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,[1] wobei damit (der umgangssprachlich häufigen Gleichsetzung von Internet und WWW[2] folgend) meist speziell URLs von Webseiten gemeint sind.

Aufbau

Der grundsätzliche URL-Aufbau besteht aus einer die Zugriffsmethode festlegenden Schema-Bezeichnung (englisch scheme) und einem Schema-spezifischen Teil (scheme-specific part), die durch einen Doppelpunkt getrennt sind: 

<scheme>:<scheme-specific-part>

Schema (scheme)

Legt fest, mit welcher technischen Methode die Ressource angesprochen werden soll.[3] 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[4] (zum Schreiben einer E-Mail) oder file[5] (zum Zugriff auf lokale Dateien).

Schema-spezifischer Teil (scheme-specific part)

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).

Benutzer und Kennwort (user, password)

Falls benötigt, können Login-Informationen aus Benutzername (user) und Kennwort (password) mit übermittelt werden.[6] 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![7] 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.

Port

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.

Pfad (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.[8] 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.

Abfrage (Query)

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

Fragment

Fragmentbezeichner 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: 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.

Beispiele

Für http(s): 

 |-------------------- Schema-spezifischer Teil ----------------------|
 | |
https://maxmuster:geheim@www.example.com:8080/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.[10] File-URLs werden beispielsweise in der Programmiersprache Java verwendet, um auf diese Weise auf lokale Dateien zuzugreifen.[11] Je nach Browser ist oftmals das Öffnen von file-Links nur nach spezieller clientseitiger Konfiguration oder unter Zuhilfenahme von AddOns etc. möglich.

Konkrete Beispiele

  • 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

Relative URLs

Neben den bisher dargestellten absoluten oder vollständigen URLs gibt es auch relative URLs. 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 URLs für http, https, ftp
Beginn Bedeutung Anmerkung Beispiel
// Selbes Protokoll sinnvoll, um http: oder https: der momentanen Umgebung zu verwenden //example.com/pfad/zu/datei
/ Selbe Domäne (host:port), „Wurzelverzeichnis“ /pfad/zu/datei
# Selbe Ressource Wirkung über Nebenwirkung #
#fragment Selbe Ressource, Sprungmarke #knoten
nichts Selbe Ressource
../ ein Pfad-Segment aufwärts Ein Server muss keine durch / gegliederte Pfad-Segmentierung unterstützen. /pfad/zur/../zur/datei
./relativer/pfad
./
sonstige		 Selbes Pfad-Segment

Relative URLs 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.

Liste erlaubter Zeichen

Reservierte Zeichen sind:

  • Sonderzeichen / ? # [ ] @ : & ' ( ) * + , ; =

Nicht reservierte Zeichen sind:

  • Buchstaben A–Z, a–z
  • Ziffern 0–9
  • Sonderzeichen - . _ ~

In bestimmten Fällen ist außerdem das Leerzeichen ␣ (dieses alternativ auch mit +[12] oder %) in Prozentkodierung (%20) darzustellen.[13]

Sprachgebrauch

Im deutschen Sprachgebrauch hat URL häufig den weiblichen Artikel, wird aber auch mit männlichem Artikel verwendet.

  • Die Wahl des Genus hängt davon ab, ob es in Anlehnung an die deutsche Übersetzung die Adresse (feminin) gebildet wird oder mittels der Grammatikregel, dass Hauptwörter auf -or (hier Locator oder -identifikator) oder -er (-bezeichner, -lokalisierer, -anzeiger) im Deutschen stets maskulin sind.

URLs in Texten

Anhang C von RFC 3986 empfiehlt, URIs (und damit auch URLs) in Texten

  • eigenständig auf einer Zeile,
  • mit doppelten Anführungsstrichen "http://example.com/" oder
  • mit spitzen Klammern <http://example.com/>

gegen den Kontext und vor allem gegen die Interpunktion des Satzes abzugrenzen.

URLs und Suchmaschinen

Auch wenn URLs technisch komplex aufgebaut sein können, können schlecht gestaltete URLs die Auffindbarkeit von Inhalten durch Suchmaschinen behindern.

  • Aus diesem Grund empfiehlt der Suchmaschinenbetreiber Google z. B. 
  • den bedachten Einsatz von Parametern in URLs. Google hat auch die Begrifflichkeit der kanonischen URL eingeführt.
  • Eine kanonische URL ist demnach die URL der Seite, von der Google annimmt, dass sie die repräsentativste von mehrfachen Verweisen auf einer Website ist.
  • Aus Sicht einer Suchmaschine sind z. B. 
  • die URL-Varianten "http://www.example.com/" , "http://example.com/" , "https://www.example.com/" und "https://example.com/"vier eigenständige Versionen, die – wenn keine kanonische URL definiert ist – zu "Duplicate-Content" und damit einer suboptimalen Sichtbarkeit führen können.

Die Prüfung der URL-Struktur wird oft im Rahmen der sogenannten Suchmaschinenoptimierung durchgeführt.

Geschichte

Name und Standardisierung

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

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.
  • Stattdessen wurde von der Gruppe der bescheidenere Begriff uniform (engl. 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.

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

Bestandteile

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:[15]

  • Der Pfad (http://www.example.com/verzeichnis/unterverzeichnis/datei.html) zitiert direkt die Pfad-Syntax in UNIX-Dateisystemen.[15]
  • 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.[15]
  • 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.[15]


Anhang

Siehe auch

RFC

Links

Weblinks
  1. ↑ Duden – Deutsches Universalwörterbuch. 6. Auflage.
  2. ↑
  3. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens rfc3986_3_1 wurde kein Text angegeben.
  4. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens mailto_scheme wurde kein Text angegeben.
  5. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens file_scheme wurde kein Text angegeben.
  6. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens rfc3986_3_2_1 wurde kein Text angegeben.
  7. ↑ Vorlage:RFC-Internet
  8. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens rfc3986_3_3 wurde kein Text angegeben.
  9. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens rfc3986_3_4 wurde kein Text angegeben.
  10. ↑ Vorlage:RFC-Internet
  11. ↑
  12. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens SO-URL-Encoding wurde kein Text angegeben.
  13. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens W3-School wurde kein Text angegeben.
  14. ↑ Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens w3_naming_schemes wurde kein Text angegeben.
  15. ↑ 15,0 15,1 15,2 15,3
Abgerufen von „https://wiki.foxtom.de/index.php?title=Uniform_Resource_Locator&oldid=92133“