1. 1
URL – Erinnerung an die Vorlesung
Schemenspezifischer Teil:
„//“[benutzer[„:“passwort]„@“]host[„:“port]„/“pfad
(eckige Klammern kennzeichnen optionalen Eintrag)
■ Benutzer – sinnvoll nur bei Zugriffsbeschränkungen auf die
Ressource
■ Passwort – zur Authentifikation eines Benutzers
■ Hostname – vollständig qualifizierender Name oder IP-Adresse
■ Portnummer – Verbindungsport für aufzubauende Verbindung;
ist bei meisten Diensten bereits festgelegt
■ Pfadname – spezifiziert, wie auf angegebenen Host mit
angegebenem Dienst auf die Ressource zugegriffen werden kann
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

2. 2
RFC 1738 – URL
■ RFC 1738, Seite 4 legt das generelle Muster für den
schemenspezifischen Teil von URLs fest
■ User, Passwort, Port und Pfad sind optional
■ Fällt das Passwort ganz weg (kein leeres Passwort), so fällt auch
der Doppelpunkt weg
■ Nach dieser Aussage folgt jede URL die mit “//” beginnt diesem
allgemeinen “common Internet scheme syntax”
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

3. 3
RFC 1738 – URL
Authentication und Credentials
■ Es macht einen Unterschied ob ein “leeres” Passwort oder kein
Passwort angegeben wird (RFC 1738, Seite 5)
■ Zulässig sind daher:
□ //user:password@host
□ //user:@host (User der kein Passwort benötigt)
□ //user@host (User muss später das Paswort angeben)
□ //@host (Leerer Benutzername, Passwort später)
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

4. 4
RFC 1738 – URL
Authentication und Credentials
■ FTP – Benutzername und Passwort
■ Auf Seite 6, RFC 1738 wird also das allgemeine Schema bzgl.
Benutzername und Passwort in der URL für FTP bestätigt und
konkretisiert.
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

5. 5
RFC 1738 – URL
Authentication und Credentials
■ HTTP - Benutzername und Passwort
■ Für HTTP hebt der Standard auf Seite 8 die Zulässigkeit für
Nutzername und Passwort in der URL wieder auf
 Widerspruch mit Seite 4, RFC 1738
■ Obwohl viele Browser Nutzername und Passwort in HTTP-URLs
unterstützen (oder dies in der Vergangenheit getan haben), war
dieses Muster für HTTP niemals Teil des Standards
 Man spricht in diesem Fall von einem De-Facto-Standard
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

6. 6
RFC 3968 – URI
Authentication und Credentials
■ RFC 3968, Seite 17 ordnet die Verwendung von Nutzernamen und
Passwort generell als “deprecated”, also veraltet, ein.
■ Tatsächlich ist die Verwendung von vertraulichen Passwörtern in
URLs keine gute Idee:
□ HTTP-Verkehr ist unverschlüsselt und kann abgehört werden
□ Speichern dieser URLs als Bookmarks ist inhärent
gefährlich, da die Passwörter dort im Klartext vorliegen
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

7. 7
RFC 1738 – URL
das mailto-Schema
■ mailto-URLs weichen nach RFC 1738 und RFC 2368 ebenfalls vom
allgemeinen URL-Muster ab:
■ mailto-URLs haben kein “//” vor dem schemenspezifischen Teil
■ #mailbox ist eine einzelne E-Mail Adresse oder eine Liste von
Adressen nach RFC 822
■ mailto-URLs können auch E-Mail Headerfelder als “Parameter”
enthalten, z.B. mailto:you@me.com?subject=Hello%20World
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

8. 8
RFC 1738 – URL
der „url-path“
■ Nach RFC 1738, Seite 5 ist der “url-path” aus dem allgemeinen
URL-Muster schemenspezifisch zu interpretieren
■ Demnach ist der “/” in URLs zwischen Host/Port und Pfad zur
Ressource nach RFC 1738 nicht optional:
□ http://openhpi.de  nicht standardkonform
□ http://openhpi.de/  standardkonform
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

9. 9
RFC 3986 – URI
URI Syntax und der „hier-part“
■ Nach RFC 3986 sieht es anders aus mit dem führenden “/” im Pfad
■ Auf Seite 15 wird festgelegt, dass der schemenspezifische Teil einer URI
mit dem hierarchischen Teil (“hier-part”) beginnt, der aus “//”, der
“authority” (z.B. Hostname und Port) und “path-abempty” besteht
■ Auf Seite 21 wird dann klar, dass ein “path-abempty” tatsächlich auch leer
sein kann – der führende “/” wird nicht benötigt, ist aber nicht verboten
□ http://openhpi.de  standardkonform
□ http://openhpi.de/  standardkonform
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

10. 10
RFC 1738 – URL vs. RFC 3986 – URI
Gültigkeit der FTP-URL
■ URL aus der Aufgabe: ftp://ftp.uni-potsdam.de/?port=20
■ Bei FTP werden Teile nach dem Hostnamen als Dateipfad interpretiert
■ Nach RFC 1738, Seite 17 ist die URL zulässig, “?” und “=” dürfen zum Pfad
gehören (siehe “fsegment”)
■ Nach RFC 3986, Seite 12 sind “?” und “=” aber reservierte Zeichen
URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems