zulässige Protokolle für URL() constructor
Michael_K
- javascript
Hallo,
ich würde gerne wissen, welche Protokolle beim URL() constructor zulässig sind. Ich habe versucht, in der Spezifikation (Link) mehr in Erfahrung zu bringen, aber kann dazu nichts finden.
Meine Frage/Problem bezieht sich darauf, dass man scheinbar keine eigenes Protocol für den constructor nutzen kann bzw. sich dieser dann anders verhält. Zum Beispiel:
alert(new URL('https://dymmy.com/file whith white space.xml').toString());
alert(new URL('zip://dymmy.com/file whith white space.xml').toString());
Im obigen Fall wird das Leerzeichen bei "zip://" nicht konvertiert, was mich etwas überrascht. Oder gibt es eine Möglichkeit, wie ich ein eigenes Protocol verwenden kann?
Gruss, Michael
Hi,
ich würde gerne wissen, welche Protokolle beim URL() constructor zulässig sind.
kannte ich bisher nicht, ich sehe auch den Einsatzzweck nicht. Aber ich würde doch spontan sagen: Alle die Protokolle, die dem Betriebssystem, unter dem der Code läuft, bekannt sind.
Meine Frage/Problem bezieht sich darauf, dass man scheinbar keine eigenes Protocol für den constructor nutzen kann bzw. sich dieser dann anders verhält.
Das meine ich: Die verlinkte Spec beschreibt doch die Realisierung der Funktion URL(). Damit etwas Sinnvolles rauskommt, muss das Betriebssystem das verwendete Protokoll kennen und unterstützen.
alert(new URL('https://dymmy.com/file whith white space.xml').toString()); alert(new URL('zip://dymmy.com/file whith white space.xml').toString());
Liegt's an der falschen Schreibweise von with?
Nein, ernsthaft: Was soll zip:// für ein Protokoll sein?
Im obigen Fall wird das Leerzeichen bei "zip://" nicht konvertiert, was mich etwas überrascht.
Weil dein OS sagt: "Hey, was'n das? Kenn ich nicht!"
Oder gibt es eine Möglichkeit, wie ich ein eigenes Protocol verwenden kann?
Vermutlich ja: Installiere einen Handler für das gewünschte Protokoll, der die nötige Funktionalität bereitstellt.
Ciao,
Martin
Hallo Martin
kannte ich bisher nicht, ich sehe auch den Einsatzzweck nicht.
Mit dem URL constructor kann man sehr gut relative URLs auflösen, was nicht immer sehr trivial ist. Und dafür nutze ich es auch. Zum Beispiel new URL(relativePath, baseURL).toString()
Aber ich würde doch spontan sagen: Alle die Protokolle, die dem Betriebssystem, unter dem der Code läuft, bekannt sind.
Wie erkennt eine JS-Engine, welche Protokolle vom OS unterstützt werden. und http ist ja nicht wirklich ein OS-Protokoll (?)
Liegt's an der falschen Schreibweise von with?
Nein, das Beispiel sollte nur veranschaulichen, dass beim ersten alert die Leerzeichen in der URL gewandelt werden. Beim zweiten Alert mit dem protocol scheme "zip:" werden die Leerzeichen nicht in %20 gewandelt. Interessant ist aber, dass die relativen URL trotzdem richtig aufgelöst werden. Es scheint, das nur bei bestimmten protocol scheme gewandelt wird. aber ich möchte eben wissen, für welche das gilt. Bei "file://" wird z.B. auch gewandelt. Bei "resource://" aber nicht, obwohl das protocol scheme bekannt ist. (grübel)
Vermutlich ja: Installiere einen Handler für das gewünschte Protokoll, der die nötige Funktionalität bereitstellt.
Wie meinst du das? Meine aktuelle Lösung ist, dass ich den Anfang des Strings prüfe auf zip:// und für den URL constructor austauschen um danach ihn wieder einzusetzen. Das ist aber keine schöne Lösung. Und zudem brauche ich eine Lösung, die in allen gängigen Browsern funktioniert.
Der Einsatzzweck bei mir ist eine Zip-Datei, deren Inhalt mit JavaScript in ein JS-Object entpackt wird. Die Dateien in der Zip-Datei enthalten Verlinkungen untereinander, die für die Verarbeitung aufgelöst werden müssen.
Gruss
Hi Michael,
Mit dem URL constructor kann man sehr gut relative URLs auflösen, was nicht immer sehr trivial ist. Und dafür nutze ich es auch. Zum Beispiel new URL(relativePath, baseURL).toString()
okay, das hört sich sinnvoll an.
Aber ich würde doch spontan sagen: Alle die Protokolle, die dem Betriebssystem, unter dem der Code läuft, bekannt sind.
Wie erkennt eine JS-Engine, welche Protokolle vom OS unterstützt werden.
Gar nicht. Sie muss es einfach annehmen.
und http ist ja nicht wirklich ein OS-Protokoll (?)
Nicht im engeren Sinn. Aber all diese Anwendungsprotokolle müssen vom TCP/IP-Protokollstack erkannt und unterstützt werden, der seinerseits dem OS angegliedert ist.
Unter Windows wird zum Beispiel das Protokoll tel: erkannt, sobald Skype oder eine vergleichbare Applikation installiert ist und sich dafür zuständig erklärt; dasselbe gilt für das Pseudoprotokoll onenote:, das von der Notiz-Applikation OneNote unterstützt wird (die locker mit der MS-Office-Suite zusammenhängt).
Nein, das Beispiel sollte nur veranschaulichen, dass beim ersten alert die Leerzeichen in der URL gewandelt werden. Beim zweiten Alert mit dem protocol scheme "zip:" werden die Leerzeichen nicht in %20 gewandelt.
Vermutlich weil sich kein Handler findet, der sich für zip: zuständig erklärt. Also bleibt das unbehandelt.
Interessant ist aber, dass die relativen URL trotzdem richtig aufgelöst werden.
In der Tat, das überrascht mich auch.
Bei "file://" wird z.B. auch gewandelt. Bei "resource://" aber nicht, obwohl das protocol scheme bekannt ist. (grübel)
Sowohl http:, als auch file:, als auch ftp: sind Standardprotokolle, die vom TCP/IP-Protokollstack normalerweise out of the box unterstützt werden. Dagegen ist mir resource: unbekannt.
Vermutlich ja: Installiere einen Handler für das gewünschte Protokoll, der die nötige Funktionalität bereitstellt.
Wie meinst du das?
Ein Programm oder eine Bibliothek (DLL), das diese Funktionalität mitbringt.
Der Einsatzzweck bei mir ist eine Zip-Datei, deren Inhalt mit JavaScript in ein JS-Object entpackt wird. Die Dateien in der Zip-Datei enthalten Verlinkungen untereinander, die für die Verarbeitung aufgelöst werden müssen.
Dazu musst du nicht nur das Protokoll erkennen, sondern auch die zugehörige Funktionalität (Zugriff auf zip-Archive) im Hintergrund bereitstellen. Das heißt, du musst dich darauf verlassen, dass beim Client eine passende Software installiert ist.
Ciao,
Martin
Hallo Michael_K,
vielleicht bin ich ja unwissend, aber was für ein Tool entpackt in JS Zip-Dateien an Hand eines zip: Schemas in der URL?
Grundsätzlich definiert die Spec sieben spezielle Schemas für den URL Konstruktor: http, https, file, ftp, ws und wss. Nur für diese Schemas kann eine Domain angegeben werden.
resource: ist, soweit ich das finden kann, eine Firefox-Spezialität.
zip: ist als Schema nicht mal in der langen Liste der IANA zu finden.
Möglicherweise hast Du dafür einen Protocol-Handler installiert. Allerdings finde ich auf die Schnelle kein Tool, das sich rühmt, einen Protocol Handler für das zip Schema bereitzustellen.
Insofern ist es kein Wunder, wenn sich URL bei zip: anders verhält als bei file: oder http:
Rolf
@@Rolf B
Grundsätzlich definiert die Spec sieben spezielle Schemas für den URL Konstruktor: http, https, file, ftp, ws und wss. Nur für diese Schemas kann eine Domain angegeben werden.
Was ist mit gopher
?
LLAP 🖖
Hallo Gunnar,
Was ist mit gopher?
Dead as a Dodo. Kein Browser pflegt diese Ratte noch, außer Lynx, und der kann kein JavaScript.
In der Spec steht das, was ich geschrieben habe.
Für alle weiteren Fragen wende dich an Veronica.
Rolf
gopher nicht vergessen. Hab ich getestet, kann an URL zugewiesen werden.
MFG
Hallo Rolf,
vielen Dank für die Information. Ich bin trotzdem weiterhin verwundert, warum die JS-Engine sowohl bei Chromium als auch die von Firefox bei einigen "vordefinierten" Protokollen die zulässige URL bei der Umwandlung in eine String encoded und bei anderen nicht.
Ich würde es ja verstehen, wenn der URL constructor einen Fehler wirft, weil die URL nicht zulässig ist weil das Protokoll nicht bekannt ist. Passiert aber nicht. Als URL wäre laut URL Spezifikation auch so etwas erlaubt "zip:somewhere/is a file.xml". Aber in diesem Fall werden die Leerzeichen auch nicht gewandelt. Ich kann nirgendwo in der Spezifikation die Stelle finden, warum nur bei einigen Protokollen die Leerzeichen und zulässigen Sonderzeichen gewandelt werden.
vielleicht bin ich ja unwissend, aber was für ein Tool entpackt in JS Zip-Dateien an Hand eines zip: Schemas in der URL?
Ich habe den Anwendungsfall, dass eine Zip-Datei via URL oder als File geladen und entpackt werden muss. Das passiert via JS (JSzip). Dies ist zwar nicht ganz so performant, aber die Zip-Dateien sind nicht zu gross und die Performance ist somit akzeptabel. Zumal das alles in einem WebWorker läuft.
In der Zip-Datei liegen Dateien, die miteinander verbunden sind und ausgelesen werden müssen. Da es noch immer kein einheitliches filesystem gibt, werden die files der Zip Datei in einem Object zips[zipPath] = zipFile abgelegt; Damit es zu keiner Verwechslung kommt, soll der 'zipPath' absolut sein. Deshalb hatte ich mir "zip://" ausgedacht, damit ich später schnell erkennen kann, woher die Datei kommt. Das klappt auch ganz gut, nur ist es eben ein Problem, wenn die URL nicht einheitlich behandelt wird, da dann die URL als key beim Zugriff auf den Inhalt vom Object nicht passt.
Ich denke, ich kann jetzt mit meiner Lösung erst einmal weiterarbeiten, ich hätte nur gerne verstanden, auf welcher Basis diese unterschiedliche Behandlung von zulässigen URLs erfolgt.
Gruss, Michael
@@Der Martin
ich würde gerne wissen, welche Protokolle beim URL() constructor zulässig sind.
kannte ich bisher nicht, ich sehe auch den Einsatzzweck nicht.
Gerade gestern erst verwendet: new URL(href).hostname
, um an den Hostnamen aus dem URL-String href
zu kommen.
(Sicher könnte man auch einen regulären Ausdruck drauf loslassen, aber warum sollte man? Unnötig fehleranfällig.)
LLAP 🖖