URI

Ein Uniform Resource Identifier (URI) ist eine Zeichenfolge, die zur Identifizierung einer abstrakten oder physikalischen Ressource dient.

Ressourcen sind Dokumente und Daten aller Art, wie zum Beispiel Grafiken, Dateien, HTML-Dokumente, Usenet-Beiträge, Telefonnummern, IRC-Channels oder (XML-)Namensräume.

Das Akronym URI wurde mit RFC 1630 [RFC-1630 1994] im Juni 1992 von Tim Berners-Lee im Rahmen seines Projekts »World Wide Web« am CERN-Institut eingeführt. Aktuell ist RFC 3986 [RFC-3986 1998] aus dem Jahr 2005.

URIs sind entweder absolut, oder sie sind relativ zu einem Basis-URI.

Absolute URIs sind wie folgt aufgebaut:

<Schema>:<schemenspezifischer Teil>

Der erste Teil eines URI gibt das Schema an, das die Interpretation des folgenden Teils festlegt. Unter http://www.iana.org/assignments/uri-schemes.html finden Sie eine Liste aller erlaubten URI-Schemata. Tabelle 2.3 führt die Schemata auf, mit denen Sie es im Webentwickleralltag am häufigsten zu tun haben.

Der schemenspezifische Teil vieler URI-Schemata, beispielsweise http oder ftp, besitzen einen hierarchischen Aufbau. Die in eckige Klammern eingeschlossenen Teile sind optional.

<Schema>://[<Benutzer>[:<Passwort>]@]<Server>[:<Port>]/
  <Pfad>?<Parameter>

Ports (Anschlüsse) sind Adresskomponenten, die in Netzwerkprotokollen wie HTTP eingesetzt werden, um Datenpakete den richtigen Diensten (Protokollen) zuzuordnen. Damit können unterschiedliche Dienste unter derselben Adresse und somit auf demselben Rechner betrieben und einzeln angesprochen werden. Ein Webserver beispielsweise ist im Allgemeinen unter Port 80 zu erreichen, FTP-Server für Dateitransfers unter Port 21.

Bei relativen URIs werden Schema, Server und Port sowie gegebenenfalls Teile des Pfads weggelassen. Den genauen Aufbau eines URI entnehmen Sie bei Interesse RFC 3986, Abschnitt 3.

Ein URI ist entweder ein URL, ein URN oder beides.

URL

Der Begriff Uniform Resource Locator (URL), der im allgemeinen Sprachgebrauch oftmals anstelle von URI verwendet wird, bezeichnet eine Unterart des URI und identifiziert eine Ressource über ihren primären Zugriffsmechanismus.

Wie Tabelle 2.4 zeigt, ist http://example.com/verzeichnis/dokument ein klassischer URL (vergleiche oben angeführten Aufbau):

Der URL lässt sich wie folgt lesen:

• Es gibt ein via HTTP verfügbares Dokument,
• das sich auf einem Rechner (Server) example.com befindet
• und dort über den Pfad verzeichnis/dokument erreichbar ist.

Andere Schemata, die Ihnen häufig begegnen werden, sind ftp://user:password@example.com für FTP und mailto:webmaster@example.com für die Angabe von E-Mail-Adressen.

Einige URLs verweisen auf eine Stelle innerhalb einer Ressource. Diese Art von URI endet mit #, gefolgt von einem Bezeichner für einen Anker (Fragmentbezeichner). Zum Beispiel zeigt dieser URL auf einen Anker namens fragment: http://example.com/verzeichnis/dokument#fragment.

Relative URLs

Ein relativer URL enthält keinerlei Schema-, Server- oder Portinformationen. Sein Pfad verweist auf eine Ressource auf demselben Server wie das aktuelle Dokument, vom dem es ausgeht. Ein relativer URL kann Pfadkomponenten und auch Fragmentbezeichner enthalten.

Einige Beispiele sollen dies verdeutlichen:

Sie können auch auf Verzeichnisse anstatt auf Dokumente verweisen. In dem Fall wird entweder ein sogenanntes Verzeichnislisting präsentiert, das Ihnen den Inhalt des Verzeichnisses anzeigt, oder es befindet sich eine Datei im Verzeichnis, die dann standardmäßig vom Browser angezeigt wird. Welche Dateien das sein können, ist abhängig von der Serverkonfiguration, generell sind das aber zumindest die Dateien index.html und/oder index.htm. Bei den beiden folgenden Verweisen würde also jeweils dieselbe Ressource angezeigt werden; in diesem Fall eine Webseite.

wsdev/einfuehrung/index.html
wsdev/einfuehrung/

Eine weitere Möglichkeit für relative Verweise ist der Verweis relativ zum Document Root, also zum Hauptverzeichnis Ihrer Website, in dem alle anderen Dateien und Unterverzeichnisse liegen. Ein solcher Verweis hat immer einen Schrägstrich (/) am Anfang des Verweisziels. Dazu zwei Beispiele:

/downloads/datei.zip
/

Der erste URL verweist ausgehend vom Document Root auf eine datei.zip in dem Unterverzeichnis downloads. Der zweite URL verweist direkt zum Document Root. Es würde also entweder ein Verzeichnislisting oder die Datei index.html angezeigt werden.

Abb. 2.3: Beispiel eines Verzeichnislistings

Verweise auf Verzeichnisse und Verweise relativ zum Document Root funktionieren nur in einer Webserverumgebung (oder direkt im Stammverzeichnis eines Laufwerks).

Das Installieren und Einrichten eines Webservers, beispielsweise des Apache HTTP Servers, ist keineswegs schwierig. Wenn Sie eine lokale Entwicklungsumgebung ausprobieren möchten, empfehle ich Ihnen XAMPP. Dabei handelt es sich um eine Zusammenstellung verschiedener Programme, Dienste und Module, darunter der Apache Webserver, die Datenbank MySQL sowie die Programmier- beziehungsweise Skriptsprachen PHP und Perl.

Probleme mit URLs

Das Konzept von URLs bringt einige Probleme mit sich. Wenn die Ressource verschoben wird, zum Beispiel auf einen anderen Server, ist sie über den ursprünglichen URL nicht mehr erreichbar. Auch gibt es stets mehrere Möglichkeiten, eine Ressource über URLs zu adressieren. Folgende URLs können unter Umständen zu derselben Ressource führen, und dabei habe ich relative URLs noch ausgelassen:

http://example.com/verzeichnis/dokument
http://example.com/verzeichnis/dokument.xhtml
http://www.example.com/verzeichnis/dokument
http://www.example.com:80/verzeichnis/dokument
ftp://ftp.example.com/verzeichnis/dokument

URNs könnten dieses Problem beheben.

URN

Ein Uniform Resource Name (URN) mit dem URI-Schema urn identifiziert eine beliebige Ressource mittels eines vorhandenen oder frei zu vergebenden Namens und ist auf Lebensdauer fest mit der Ressource verbunden, ganz gleich, wo und wie diese erreichbar ist. Ein URN besteht im Wesentlichen aus Ziffern, beispielsweise urn:isbn:3-8273-2477-7 oder urn:zbl:0949.68057.

Anders als URLs, die nicht die Ressource selbst angeben, sondern nur den Ort, an dem sie liegt, vergibt ein URN einer Ressource eine unveränderliche Kennung, anhand deren das Dokument unabhängig von seinem Ablageort identifiziert werden kann, ähnlich einer ISBN bei Büchern.

URNs können heute nicht direkt aufgerufen werden. Vielmehr müssen sie erst in URLs übersetzt werden, die nicht unbedingt die direkte gesuchte Ressource bezeichnen müssen, sondern auch zu Metainformationen oder Bezugsquellen führen können. So wäre es beispielsweise denkbar, dass ein Benutzer beim Aufruf des oben aufgeführten URNs nicht zum Volltext des Buchs, sondern zur Produktseite seines bevorzugten Onlinebuchhändlers geleitet wird.

Zum Auffinden der Dokumente wird eine zentrale Instanz benötigt, die die URNs in gültige URLs auflöst. Diese Aufgabe übernehmen derzeit die nationalen Bibliotheken.

Zum Seitenanfang

HTTP

Das Hypertext Transfer Protocol (HTTP) wurde 1990 vom Tim Berners-Lee im Rahmen seines Projekts »World Wide Web« am CERN-Institut entwickelt. Es ist ein Kommunikationsschema zum Austausch von Daten und noch heute das Standardprotokoll des Webs. Es gibt derzeit zwei Versionen: 1.0 [RFC-1945 1996] und 1.1 [RFC-2616 1999].

HTTP wird primär zur Anfrage und Übertragung von Webressourcen verwendet. Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Fehlercodes im Rahmen von HTTP 1.1 wird es zunehmend zum Austausch beliebiger Daten zwischen Clients und Servern genutzt, beispielsweise auch zur Durchführung von Dateitransfers (Downloads und Uploads).

Protokollaufbau

Immer dann, wenn Sie einen URI in die Adresszeile eines Browsers tippen und die Ressource anfordern oder wenn Sie einem Link folgen, baut der Browser eine HTTP-Verbindung auf. Bei jeder Verbindung wird zwischen dem Browser (Client) und dem Server, auf dem die angeforderte Ressource liegen soll, ein HTTP-Nachrichtenpaar ausgetauscht, und zwar ein HTTP-Request (Anfrage) des Clients und ein HTTP-Response (Antwort) des Servers. Eine HTTP-Nachricht besteht aus mehreren Zeilen, die durch einen Zeilenumbruch (genauer: Wagenrücklauf und Zeilenvorschub, kurz CRLF für »Carriage Return« und »Line Feed«) abgeschlossen werden.

Ein HTTP-Request ist schematisch wie folgt aufgebaut:

Request-Zeile
[Message-Header CRLF]*
CRLF
[Message-Body]

Die Request-Zeile gibt die Request-Methode, einen URI sowie die Protokollversion an. Anschließend können einige Message-Header-Zeilen mit Request-Parametern und Clientinformationen folgen. Eine Leerzeile beendet den HTTP-Request oder trennt den Message-Header vom Message-Body, falls ein solcher folgt.

Ein HTTP-Response hat einen fast identischen Aufbau:

Status-Zeile
[Message-Header CRLF]*
CRLF
[Message-Body]

Die Statuszeile besteht aus der Protokollversion und einem Erfolgs- oder Fehlercode. Ihr folgen Message-Header-Zeilen, die Server- und Metainformationen enthalten. Auch hier beendet eine Leerzeile den HTTP-Response oder trennt gegebenenfalls Message-Header und Message-Body voneinander.

Mit einem HTTP-Sniffer wie zum Beispiel http://web-sniffer.net lassen sich Befehle und Daten, die bei einer Verbindung ausgetauscht werden, sehr einfach einsehen. Ein Aufruf der Adresse http://www.example.com/ im Browser könnte folgenden HTTP-Request an den Server senden:

GET / HTTP/1.1[CRLF]
Host: www.example.com[CRLF]
Connection: close[CRLF]
Accept-Encoding: gzip[CRLF]
Accept: text/xml, application/xml,
application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,
image/png,*/*;q=0.5[CRLF]
Accept-Language: en-us,en;q=0.5[CRLF]
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7[CRLF]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.1) Gecko/20040707 [CRLF]
[CRLF]

In der Request-Zeile fordert der Client eine Ressource mit der Methode GET an und gibt zudem an, HTTP der Version 1.1 zu verstehen. In diesem Fall adressiert der URI kein konkretes Dokument, sondern den Document Root. Es ist abhängig von den Servereinstellungen, welche Ressource zurückgeliefert wird, in vielen Fällen ist es die Datei index.html. Als Nächstes folgen die Message-Header-Zeilen. Das Feld Host gibt den Domainnamen des Webservers und gegebenenfalls den Port an. Mit dem Feld Connection kann der Sender Optionen beschreiben, die nur für eine Verbindung gelten. Hier soll die Verbindung nach erfolgtem Response geschlossen werden. Accept-Encoding beschränkt die kodierbaren Inhalte, Accept spezifiziert, über q-Werte (quality values) relativ gewichtet, die akzeptierbaren MIME-Typen, Accept-Language die bevorzugte Sprache, Accept-Charset den akzeptierbaren Zeichensatz. Das Feld User-Agent übermittelt Angaben über den Browser, in diesem Beispiel ein Mozilla der Version 1.7.1 unter Windows.

Der HTTP-Response des Servers auf diesen Request könnte wie folgt aussehen:

HTTP/1.1 200
OK
Date: Wed, 25 Aug 2004 18:18:43 GMT [CRLF]
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) [CRLF]
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT [CRLF]
ETag: "3f80f-1b6-3e1cb03b" [CRLF]
Accept-Ranges: bytes [CRLF]
Content-Length: 438 [CRLF]
Connection: close [CRLF]
Content-Type: text/html [CRLF]
[CRLF]
<HTML>[CRLF]
<HEAD>[CRLF]
<TITLE>Example Web Page</TITLE>[CRLF]
</HEAD>[CRLF]
<body>[CRLF]
<p>You have reached this web page by typing
&quot;example.com&quot;,[CRLF]
&quot;example.net&quot;,[CRLF]
or &quot;example.com&quot; into your web
browser.</p>[CRLF]
<p>These domain names are reserved for use in
documentation
and are not available [CRLF]
for registration. See <a href="http://www.rfc-
editor.org/rfc/rfc2606.txt">RFC [CRLF]
2606</a>, Section 3.</p>[CRLF]
</BODY>[CRLF]
</HTML>[CRLF]
[CRLF]

Die Statuszeile gibt hier den Erfolgscode 200 OK an, es ist also kein Fehler aufgetreten. Die Bedeutung der HTTP-Header-Felder erklärt sich von selbst oder ist – wenn Sie tiefer in das Thema einsteigen möchten – in RFC 2616 nachzulesen. Dort finden Sie in Abschnitt 10 auch sämtliche Statuscode-Definitionen aufgeführt. Mit einer Leerzeile vom HTTP-Header abgetrennt, folgt der 438 Byte lange Content-Body, wie im Feld Content-Length bereits angekündigt wurde. In diesem Fall handelt es sich um das zurückgelieferte HTML-Dokument, das der Browser nach Aufruf der Adresse http://www.example.com/ anzeigen würde.

Was leider fehlt, ist eine Angabe der Zeichenkodierung. Diese Information ist die »schwache Stelle« der Trennung von Ressource und Transfer, weil sie nicht technisch sicher in der Ressource selbst untergebracht werden kann. Das Feld Content-Type des Request-Headers der W3C-Homepage sieht besser aus, da es eine Angabe darüber enthält, welcher Zeichenkodierung das Dokument entspricht:

Content-Type: text/html; charset=utf-8

Die richtige Angabe der Kodierung verdient Ihre besondere Aufmerksamkeit und gilt als Kriterium Ihrer Kompetenz. Mehr dazu in Kapitel 2.10 »Zeichenkodierung«.

Zum Seitenanfang

MIME-Typen

Multimedia Internet Message Extensions (MIME) legen die Struktur und den Aufbau von E-Mails fest, werden im Internet aber ferner dafür verwendet, die Art der zu übertragenden Daten bei Client/Server-Verbindungen festzulegen, unter anderem auch bei HTTP.

Wie Sie bereits gesehen haben, tauschen Client und Server bei einem HTTP-Dialog Informationen über die Art der angefragten Ressource aus. Der Client sendet mittels Accept-Header eine Liste aller MIME-Typen an den Server, die er (bevorzugt) verarbeiten kann. Der Server wiederum versieht seine Antwort mit einem Content-Type-Header, in dem die Art der gesendeten Ressource und gegebenenfalls, bei textuellen Ressourcen, die verwendete Zeichenkodierung notiert sind.

Verarbeitung einer Ressource

Im Allgemeinen akzeptieren Browser Ressourcen jedes MIME-Typs. Was sie dann mit ihnen anstellen, ist abhängig von der Server-, Browser- und Systemkonfiguration, also ob sie die Ressource im Browserfenster darstellen, zum Herunterladen anbieten oder an ein anderes Programm übergeben, das diese Ressource dann anzeigt oder anderweitig verarbeitet.

• Jeder Browser kann eine unterschiedliche Menge an Dateitypen standardmäßig anzeigen; dazu gehören neben (X)HTML-Dokumenten in den meisten Fällen Textdateien, CSS-Stylesheets und Grafikformate wie GIF, JPEG oder PNG. Andere Dateitypen benötigen ein Plug-in, beispielsweise Flash oder SVG.
• Wenn der Browser die Zielressource nicht selbst verarbeiten kann, ihm aber ein Programm bekannt ist, das entsprechende Dateien verarbeitet, kann der Start dieses Programms veranlasst und die Datei an das Programm übergeben werden. Gegebenenfalls wird das Anzeigefenster des Fremdprogramms in das Browserfenster eingebettet. Dieses Verhalten ist oft bei Musik- oder Videodateien zu beobachten.
• Kann der Browser mit dem Dateityp der Zielressource nichts anfangen und ist ihm auch kein Programm bekannt, das die Datei verarbeiten kann, wird ein Dialog angeboten, in dem entschieden wird, was mit der Datei geschehen soll; auf diese Weise kann der Nutzer die Datei herunterladen. Ein solcher Dialog erscheint in den meisten Fällen bei gepackten Dateien, beispielsweise ZIP oder RAR.

Aufbau

Ein MIME-Typ wird in zwei Teilen notiert, die durch einen Schrägstrich (/) voneinander getrennt sind. Zunächst erfolgt die Angabe eines Medientyps, anschließend wird der Untertyp angeführt. Auf beiden Seiten können Sie einen Asterisk (*) als Platzhalter notieren; so steht text/* für alle Textdateien, */* für Dateien eines beliebigen MIME-Typs.

Mittlerweile gibt es so viele MIME-Typen wie Sand am Meer. Eine sehr umfangreiche und häufig aktualisierte Liste finden Sie auf der Seite MIME Media Types der IANA, die für Webautoren wichtigsten sind in Tabelle 2.6 aufgelistet.