Ursprüngliche URL jeder Webseite des www anzeigen

[forumleaks]

Zur Zeit arbeite ich an einem Vim-Makro, das den Quelltext irgendeiner Webseite in die in der Regel dort vorhandenen URLs umwandeln soll. Problematisch sind nur die relativen URL-Angaben, weil ich nicht weiß, auf welche URL sich diese beziehen.

Wenn ich also irgendeine Webseite aufrufe und dann dessen Quelltext, beziehen sich dann die relativen URL-Angaben immer auf die in der Adresszeile angezeigte URL oder gegebenenfalls auf die ursprüngliche URL?

Es gibt ja Webseiten, wo die Webadresse von beispielsweise ModRewrite in die eigentliche ursprüngliche URL dieser Seite umgewandelt wird. So kann es sein, dass die falsche Webadresse Ordner enthält, die bei der ursprünglichen URL gar nicht vorhanden sind.

Wenn aber der Browser die nicht ursprüngliche URL mit den nicht vorhandenen Ordnern anzeigt, worauf beziehen sich dann die relativen URL-Angaben im Quelltext? Auf die angezeigte Weiterleitungs-URL oder auf die mir unbekannte ursprüngliche URL?

Falls auf die unbekannte ursprüngliche URL; wie kann ich diese beispielsweise mit dem FireFox oder dem Internet Explorer oder notfalls irgend einem anderen Browser ermitteln? Oder steht diese ursprüngliche URL sogar irgendwo im Quelltext der Webseite?

Übrigens wird dieses VIM-Makro in Kürze zum Download hier zur Verfügung stehen:

http://forumtreff.pytalhost.de/406

[ChrisB]

Hi,

Wenn ich also irgendeine Webseite aufrufe und dann dessen Quelltext, beziehen sich dann die relativen URL-Angaben immer auf die in der Adresszeile angezeigte URL oder gegebenenfalls auf die ursprüngliche URL?

Natürlich auf die Adresse, von der der Client das Dokument erhalten hat - schließlich ist es Aufgabe des Clients, relative Pfadangaben zu vollständigen URLs zu ergänzen, bevor er eine Anfrage an den Server stellt.

Es gibt ja Webseiten, wo die Webadresse von beispielsweise ModRewrite in die eigentliche ursprüngliche URL dieser Seite umgewandelt wird. So kann es sein, dass die falsche Webadresse Ordner enthält, die bei der ursprünglichen URL gar nicht vorhanden sind.

Was der Server intern macht, ist dem Client vollkommen egal - der bekommt davon nichts mit.

MfG ChrisB

[dedlfix]

Hi!

Zur Zeit arbeite ich an einem Vim-Makro, das den Quelltext irgendeiner Webseite in die in der Regel dort vorhandenen URLs umwandeln soll. Problematisch sind nur die relativen URL-Angaben, weil ich nicht weiß, auf welche URL sich diese beziehen.

Das gleiche Lernpotential haben anscheinend auch die Autoren von in der Regel unerwünschten Bots. Die stückeln auch relative URL-Angaben irgendwie zusammen, nur nicht wie vorgesehen, und spammen damit als erstes das Error-Log voll.

Wenn ich also irgendeine Webseite aufrufe und dann dessen Quelltext, beziehen sich dann die relativen URL-Angaben immer auf die in der Adresszeile angezeigte URL oder gegebenenfalls auf die ursprüngliche URL?

Was soll denn die ursprüngliche URL konkret sein? Stell dir die Frage mal mit dem Hintergrund, dass du einem anderswo befindlichen Link folgst (Suchmaschine vielleicht) und "mittendrin" in einem Angebot auf einer beliebigen Seite landest. Wo ist dann deine ursprüngliche URL. Und warum sollte der Aufruf dieser Seite andere behandelt werden als wenn er über einen internen Link erfolgte?

Im Web wird stets nur der Request und die zugehörige Response zusammen behandelt und alles andere davor ist irrelevant, weil es nicht geschehen sein muss, um eine bestimmte Seite aufzurufen.

Es gibt ja Webseiten, wo die Webadresse von beispielsweise ModRewrite in die eigentliche ursprüngliche URL dieser Seite umgewandelt wird. So kann es sein, dass die falsche Webadresse Ordner enthält, die bei der ursprünglichen URL gar nicht vorhanden sind.

Das wäre dann aber ein Fehler, den der mod_rewrite-Konfigurierende nicht beachtet hat. Ein Browser bekommt von einem mod_rewrite nichts mit. Wenn also jemand mod_rewrite einsetzt, muss er dafür sorgen, dass relative Verweise zur aufgerufenen URL passen.

Wenn aber der Browser die nicht ursprüngliche URL mit den nicht vorhandenen Ordnern anzeigt, worauf beziehen sich dann die relativen URL-Angaben im Quelltext? Auf die angezeigte Weiterleitungs-URL oder auf die mir unbekannte ursprüngliche URL?

Auch wenn eine Weiterleitung ausgeführt wurde, interessiert sich der Browser nur für die URL des neuen Requests und nicht für den ider die Requests die im Weiterleitungen als Antwort eingebracht haben. Denn derjenige, der gleich auf das neue Ziel geht, weiß von einer URL mit Weiterleitung nichts. Er muss genauso wie der Weitergeleitete den Inhalt der vorliegenden Seite interpertieren.

Falls auf die unbekannte ursprüngliche URL; wie kann ich diese beispielsweise mit dem FireFox oder dem Internet Explorer oder notfalls irgend einem anderen Browser ermitteln? Oder steht diese ursprüngliche URL sogar irgendwo im Quelltext der Webseite?

"Ursprüngliche URLs" könnte es in unendlicher Anzahl geben. Wie gesagt, interessiert nicht eine einzige davon.

Lo!

[Tom]

Hello,

BTW:

ich finde das Thema ganz interessant für den Fall, dass man eine Webseitengruppe offline verfügbar machen will. Welche URLs muss man da wie umwandeln in den Dokumenten, damit das Gesamtangebot noch funktioniert?

Aufruf-URL: Domain in Pfadangabe im Dateisystem umwandeln;
  Pfadangabe: ?
  Aufrufparameter: ? soll man die Parameter anhängen lassen?

URLs im Dokument:
  Images: ?
  Script-Ressourcen: ?

absolute Pfad-Angaben (ohne Scheme und Domain)
  in relative umwandeln, signierte Elemente in den Pfaden ebenfalls herunterladen

absolute URL-Angaben mit Scheme
  zur aufgerufenen URL: in relative umwandeln
  zu weiteren URLs: ? (stehen lassen, wenn nicht mit heruntergeladen?)

...

usw.

Gibt es für diese Aufgabenstellung irgendwo schon ein schlaues Dossier?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

[...] für den Fall, dass man eine Webseitengruppe offline verfügbar machen will. Welche URLs muss man da wie umwandeln in den Dokumenten, damit das Gesamtangebot noch funktioniert?

Alles was nicht relativ zur aktuellen Seite angegeben ist. Das beinhaltet Angaben relativ zum DocumentRoot (also mit / beginnend)  und solche, die mit vollständiger URL angegeben sind, aber eigentlich hätten relativ notiert werden können. Weiterhin sind Directory-Indexe zu beachten, also alles was auf / endet (und theoretisch enden müsste, damit es keinen Redirekt auf .../ gibt) benötigt einen Dateinamen. Und Datei-Endungen wären auch interessant, die lässt man ja modernerweise gern weg.

Falls es einem der Mitlesenden nicht klar ist: Das Problem ist, dass das gespeicherte Angebot in irgendeinem Unterverzeichnis abgelegt wird und damit nicht mehr relativ zum Wurzelverzeichnis (entspricht DocumentRoot auf dem Webserver) verlinkt werden kann.

Aufruf-URL: Domain in Pfadangabe im Dateisystem umwandeln;
  Pfadangabe: ?
  Aufrufparameter: ? soll man die Parameter anhängen lassen?

Wofür? Wenn du für jede Parameterkombination eine eigene Seite speicherst, weil sich der Inhalt entsprechend ändert, dann brauchst du sie in irgendeiner Form. Sonst nicht.

URLs im Dokument:
  Images: ?
  Script-Ressourcen: ?

Müssen relativ zum aktuellen Dokument angegeben sein.

absolute Pfad-Angaben (ohne Scheme und Domain)
  in relative umwandeln, signierte Elemente in den Pfaden ebenfalls herunterladen

Was sind signierte Elemente im Pfad?

absolute URL-Angaben mit Scheme
  zur aufgerufenen URL: in relative umwandeln
  zu weiteren URLs: ? (stehen lassen, wenn nicht mit heruntergeladen?)

Ja.

Ich bin mir sicher, dass es Downloader gibt, die das alles gleich entsprechend anpassen.

Lo!

[Tom]

Hello,

Aufruf-URL: Domain in Pfadangabe im Dateisystem umwandeln;
  Pfadangabe: ?
  Aufrufparameter: ? soll man die Parameter anhängen lassen?

Wofür? Wenn du für jede Parameterkombination eine eigene Seite speicherst, weil sich der Inhalt entsprechend ändert, dann brauchst du sie in irgendeiner Form. Sonst nicht.

Die Parameter könnten auch durch JavaScript ausgewertet werden, also lokal.

URLs im Dokument:
  Images: ?
  Script-Ressourcen: ?

Müssen relativ zum aktuellen Dokument angegeben sein.

absolute Pfad-Angaben (ohne Scheme und Domain)
  in relative umwandeln, signierte Elemente in den Pfaden ebenfalls herunterladen

Was sind signierte Elemente im Pfad?

namentlich genannt, also z.B. die Bilder und Scripte

absolute URL-Angaben mit Scheme
  zur aufgerufenen URL: in relative umwandeln
  zu weiteren URLs: ? (stehen lassen, wenn nicht mit heruntergeladen?)

Ja.

Ich bin mir sicher, dass es Downloader gibt, die das alles gleich entsprechend anpassen.

Da bin ich mir auch sicher. Nur finde ich es eben interessant, WAS die alles zu tun haben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hello,

Gibt es für diese Aufgabenstellung irgendwo schon ein schlaues Dossier?

Ja, gibt es, nennt sich Projektverwaltung. Idealerweise in elektronischer Form, so dass ein Programm darauf aufsetzen kann, was die Verlinkung erledigt.

Hotti

[hotti]

Mode Rewrite mal ein bischen anders aufgeschrieben:

RewriteRule 'angeforderter URI' 'anderer URI'
RewriteRule 'angeforderter URI' 'anderer URI' [R]

Der 'angeforderte URI' ist der sog. REQUEST_URI unter diesem Namen ist er in der Serverumgebung zu finden. Der 'andere URI' kann ein serverinterner Prozess sein oder ein anderer URI auf dem gleichen Server. Wurde [R] geflaggt, erfolgt eine Redirection, d.h. der Client wird vermittels eines Location-Header zum 'anderer URI' geschickt, hierbei ändert sich die Adresszeile im Browser, der Browser requestet nacheinander zunächst den Ersten und dann den zweiten URI 'anderer URI'.

Ohne [R] bleibt der Client auf dem REQUEST_URI, die Adresszeile ändert sich nicht.

In beiden Fällen erwartet der Client eine Response von 'anderer URI'. Um die Verwirrung komplett zu machen, kann 'anderer URI' auch selbst einen Location-Header erzeugen (unabhängig von [R]) und den Client zu einem 'wiederum anderen URI' schicken.

Zu Deiner Frage zu Relativen Pfadangaben in action, href, scr...

Diese sind immer relativ zum REQUEST_URI, also zu dem URI, der letztendlich in der Adresszeile des Browsers steht.

Nehmen wir [R] aus, der Request_Uri sei /foo/bar.html (konstant) hierdrin soll ein Link in href="baz.txt" notiert sein. Der Browser wird den relativen Link ergänzen, zu sehen, wenn Du mit dem Mauszeiger drüberfährst ist: /foo/baz.txt

Mit {R] gilt die gleiche Beziehung, nur mit dem Unterschied, dass vom Request_Uri ausgehend auf eine andere Seite umgeleitet wird und sich damit ein neuer Request_Uri ergibt.

Hotti

[forumleaks]

Zu Deiner Frage zu Relativen Pfadangaben in action, href, scr...

Diese sind immer relativ zum REQUEST_URI, also zu dem URI, der letztendlich in der Adresszeile des Browsers steht.

Danke für diese klare Antwort. Übrigens hatte ich auch hier nachgefragt: Klick!

Auch funktionieren LInks mit Sprungmarke hier in diesem Forum nur, wenn man %23 durch # manuell ersetzt; also die atomatische Ersetzung rückgängig macht.

[hotti]

hi,

Auch funktionieren LInks mit Sprungmarke hier in diesem Forum nur, wenn man %23 durch # manuell ersetzt; also die atomatische Ersetzung rückgängig macht.

Aufpassen: Das Percent-Coding(Escape) # => %23 ist in dem Fall notwendig, wenn das Zeichen '#' in einer Komponente des Query_String als Parameter vorkommt.

z.B. /foo/bar?rautenzeichen=%23#anker1

Ohne Escape wird mit '#' ein Fragment eingeleitet.

Hotti

[forumleaks]

Danke an alle! Also (ausschließlich) die in der Adressleiste angezeigte URL ist maßgebend, zu der die relativen URL-Angaben passen müssen. Oder habe ich das falsch verstanden? Beispielsweise der Link zu meinem Beitrag, wo ich das Makro veröffentlichen werde, ist dieser:

http://forumtreff.pytalhost.de/406

Nach Aufruf der URL steht aber in der Adressleiste die ursprüngliche URL so ungefähr da:

http://forumtreff.pytalhost.de/viewtopic.php?t=406

Auf welche dieser beiden URLs müssen sich nun die relativen Linkangaben beziehen?

[hotti]

Auf welche dieser beiden URLs müssen sich nun die relativen Linkangaben beziehen?

auf Path

http://forumtreff.pytalhost.de/viewtopic.php?t=406#t
                                                   ^Fragment
                                             ^Query_String
                              ^Path
       ^Auth
^Scheme

Hotti

[forumleaks]

Nur schade, dass die in der Adressleiste des Browsers angegebene URL nicht im Quelltext geschrieben steht, noch nicht mal relativ. Weil aber nicht bei allen Webseiten die angeforderte URL identisch mit der in der Adressleiste erscheinenden ist,

muss diese URL dann vor jedem Makrostart manuell im zu bearbeitenden Dokument angegeben werden, was das manuelle Crawlen im Web dadurch unweigerlich leider etwas umständlicher machen wird. Oder es hätte jemand einen Tipp, wie man den Browser so umschalten kann, dass er diese URL irgendwo in den Quelltext mit hinein schreibt.

Denn so ein Quelltext besteht ja aus schier beinahe unendlich vielen Meta-Angaben, sodass der eigentliche Inhalt im Body dann geradezu untergeht unter diesen vielen Meta-Infos.

Ich vermute, dass dies sogar Absicht ist, dass man wahnsinnig werden soll, falls man sich mal einen Quelltext vorknüpft. Und dass man dann möglichst auch noch an einem Wutanfall zugrunde gehen soll; wenn man dann nämlich auch noch bemerkt, dass kein einziger dieser Metas das Wichtigste verrät, was die jeweilige Seite betrifft, nämlich deren eigentliche URL.

[hotti]

Nur schade, dass die in der Adressleiste des Browsers angegebene URL nicht im Quelltext geschrieben steht, noch nicht mal relativ.

Ich kann Dich trösten ;)
Dasselbe Probläm habe ich auch, wenn meine Callbackfunktionen eine Tabelle erzeugen, in der Tabelle brauche ich den Path als Link...

Tipp von dedlfix (2): einfach weglassen. Da steht dann im Quelltext zwar noch weniger (1), aber beim Drüberfahren mit der Maus entsteht was Brauchbares.

(1) z.B.: href="?download=xyz"

(2) die Tage, steht weiter unten im Forum.

Hotti

[Der Martin]

Hallo,

Nur schade, dass die in der Adressleiste des Browsers angegebene URL nicht im Quelltext geschrieben steht, noch nicht mal relativ.

wozu auch? Normalerweise ist die URL eines Web-Dokuments eine bekannte Größe. Wenn du das Dokument natürlich aus seinem Kontext herauslösen und isolieren willst, musst du diese Information zusätzlich speichern.

Weil aber nicht bei allen Webseiten die angeforderte URL identisch mit der in der Adressleiste erscheinenden ist

Doch, selbstverständlich. Abgesehen von Framesets, aber sobald du die Frames in eigenständigen Browserfenstern (Tabs) öffnest, gilt die Gesetzmäßigkeit wieder: In der Adressleiste steht genau die URL, unter der das Dokument angefordert wurde.

Oder es hätte jemand einen Tipp, wie man den Browser so umschalten kann, dass er diese URL irgendwo in den Quelltext mit hinein schreibt.

Zumindest der IE erzeugt beim Speichern einer Webseite einen HTML-Kommentar am Anfang des Dokuments, in dem die URL vermerkt ist, von der das Dokument gespeichert ist. Das ist aber nur ein schwacher Trost für die ansonsten schwere Verstümmelung des Quellcodes durch den IE.
Ansonsten bietet es sich an, beim Speichern einer Ressource deren URL im Datei- oder Verzeichznisnamen abzubilden.

Denn so ein Quelltext besteht ja aus schier beinahe unendlich vielen Meta-Angaben

Ach? Was für Quelltexte guckst du dir an?

sodass der eigentliche Inhalt im Body dann geradezu untergeht unter diesen vielen Meta-Infos.

Soso. Das ist mir bisher nicht untergekommen.

Ich vermute, dass dies sogar Absicht ist, dass man wahnsinnig werden soll, falls man sich mal einen Quelltext vorknüpft. Und dass man dann möglichst auch noch an einem Wutanfall zugrunde gehen soll; wenn man dann nämlich auch noch bemerkt, dass kein einziger dieser Metas das Wichtigste verrät, was die jeweilige Seite betrifft, nämlich deren eigentliche URL.

Natürlich. Und der Psychotherapeut wird vom Betreiber der Website gestellt.

So long,
 Martin