![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](https://image.slidesharecdn.com/urlerratum-130621080021-phpapp01/85/openHPI-Erratum-URL-und-URI-1-320.jpg)
openHPI Erratum: URL und URI
- 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