Resourcen im Internet identifizieren

Das Ziel einer HTTP Anfrage wird Resource genannt. Deren Eigenschaften ist nicht weiter definiert, sie könnte ein Dokument, ein Photo oder irgendwas anderes sein. Jede Resource ist identifiziert über einen Uniformen Resourcen Identifizierer (URI), welche überall in HTTP genutzt werden, um Resourcen zu identifizieren.

Die Identität und der Ort von Resourcen im Internet sind meistens gegeben über eine einzelne URL (Uniform Resource Locator, eine Art der URI). Es gibt manchmal Gründe, dass Identitä und Ort nicht von der selben URI gegeben: HTTP benutzt einen spezifischen HTTP header, Alt-Svc wenn die Resource will, dass der Client sie an einem anderen Ort anfragt.

Die häufigste Form von URI ist der Uniform Resource Locator (URL),  welche als Web Adresse bekannt ist.

https://developer.mozilla.org
https://developer.mozilla.org/en-US/docs/Learn/
https://developer.mozilla.org/en-US/search?q=URL

Jede dieser URLs kann in einen Browser eingegeben werden um mit diesem die assoziierte Seite (auch eine Resource) zu laden.

Eine URL besteht aus verschiedenen Teilen, manche werden benötigt, andere sind optional. Ein komplexeres Beispiel könnte so aussehen:

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

Ein Uniform Resource Name (URN) ist eine URI die eine Resource über einen namen in einem Namespace.

urn:isbn:9780141036144
urn:ietf:rfc:7230

Die beiden URNs korrespondieren zu

• Dem Buch Nineteen Eighty-Four von George Orwell,
• Der IETF Spezifikation 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.

http:// ist das Protokoll. Es gibt an, welches Protokoll der Browser nutzen soll. Normalerweise ist das das HTTP Protokoll oder seine gesicherte version, HTTPS. Das Internet verlangt eines der beiden, aber Browser wissen auch wie andere Protokolle wie mailto: (um einen email Client zu öffnen) oder ftp: (für einen Datentransfer) zu behandeln sind, also sollte man nicht überrascht sein wenn man solche Protokolle sieht. Häufige Schemata sind:

www.example.com ist der Domain Name oder Authorität die den Namespace verwaltet. Sie gibt an, welcher Server angefragt wird. Alternativ ist es möglich, direkt eine IP address anzugeben, aber da es weniger angenehm ist, wird es nicht häufig genutzt.

:80 ist der Port in diesem Fall. Er gibt das technologische "Tor" an, über welches die Resource auf dem Server angesprochen wird. Er wird in der Regel weggelassen wenn der Server die Standard Ports für das HTTP (80) oder HTTPS (443) Protokoll nutzt. Andernfalls wird die Portangabe benötigt.

/path/to/myfile.html ist der Pfad zu der Resource auf dem Server. Anfangs hat der Pfad einen Dateipfad auf dem Server angegeben, heutzutage ist er aber meist eine Abstraktion, die von dem Server verarbeitet wird

?schluessel1=wert1&wśchluessel2=wert2 sind extra Parameter die dem Server übergeben werden. Diese Parameter sind eine Liste von Schlüssel/Wert paaren, die mit einem & getrennt werden. Der Server kann diese Parameter nutzen um zusätzliche Sachen zu machen bevor die Resource dem Nutzer übergeben wird. Jeder Server hat eigene Regeln bezüglich Parametern und der einzig sichere Weg diese zu wissen, ist denn Besitzer des Servers zu fragen.

#SomewhereInTheDocument ist ein Anker zu einem anderen Bereich der Resource selber. Ein Anker repräsentiert eine Art "Lesezeichen" innerhalb der Resource, damit der Browser den Inhalt an der Stelle des Ankers anzeigt. In einem HTML document wird der Browser zum Beispiel an die Stelle scrollen, an der der Anker definiert ist; in einem Video oder Audio Document wird der Browser zu der entsprechenden Zeit springen. Das Fragment selber wird allerdings nie zu dem Server gesendet, es wird allein von dem Browser verarbeitet.

Wenn man URLs in einem HTML Inhalt nutzt sollte man generell nur ein paar dieser URL Schemata nutzen. Nutzt man Subresourcen — das heißt, Dateien die als Teil eines größeren Dokuments geladen werden —, sollte man nur die HTTP und HTTPS Schemata nutzen. Browser entfernen vermehrt den Support dafür, dass FTP Schema zu nutzen um Subresourcen zu laden, da dies eine Sicherheitslücker darstellt.

FTP ist immernoch akzeptiert auf dem obersten Level (zum Beispiel direkt in der URL Leiste des Browsers eingegeben, oder das Ziel eines Links), wobei manche Browser FTP Inhalte an eine andere Anwendung delegieren.

https://developer.mozilla.org/en-US/docs/Learn
tel:+1-816-555-1212
git@github.com:mdn/browser-compat-data.git
ftp://example.org/resource.txt
urn:isbn:9780141036144
mailto:help@supercyberhelpdesk.info

• What is a URL?
• IANA list of URI schemes