openHPI Erratum: URL und URI

10
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

Transcript of openHPI Erratum: URL und URI

Page 1: openHPI Erratum: URL und URI

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

Page 2: openHPI Erratum: URL und URI

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

Page 3: openHPI Erratum: URL und URI

3

RFC 1738 – URLAuthentication 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

Page 4: openHPI Erratum: URL und URI

4

RFC 1738 – URLAuthentication 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

Page 5: openHPI Erratum: URL und URI

5

RFC 1738 – URLAuthentication 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

Page 6: openHPI Erratum: URL und URI

6

RFC 3968 – URIAuthentication 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

Page 7: openHPI Erratum: URL und URI

7

RFC 1738 – URLdas 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:[email protected]?subject=Hello%20World

URL Format - Errata | openHPI Online-Kurs "Web-Technologien" | T. Staubitz, C. Willems

Page 8: openHPI Erratum: URL und URI

8

RFC 1738 – URLder „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

Page 9: openHPI Erratum: URL und URI

9

RFC 3986 – URIURI 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

Page 10: openHPI Erratum: URL und URI

10

RFC 1738 – URL vs. RFC 3986 – URIGü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