Adressanzeige
fiversen
- browser
- design/layout
- html
Hallo,
ich starte meine Seite bei https://www.xxx.de/startseite.html
Da verzweige ich auf ein cgi-script, das die Seite zusammenbaut. https://www.xxx.de/xyz/seite1.cgi
Im Browser wird diese komplex Adresszeile anzeigt.
Das ist schwierig für die Benutzer.
Geht es - das ich die Startadresse anzeige, am besten auch wenn man sich die Seite als Favorit merkt.
solong .. frank
Lieber fiversen,
https://www.xxx.de/startseite.html
oh, ist das ein Erotik-Angebot? Triple-x klingt immer nach Porno... und ist es auch. War ja klar.
Ach, Du meintest "irgendeine Domain"? Dafür gibt es allen Ernstes example.org und example.com.
Da verzweige ich auf ein cgi-script, das die Seite zusammenbaut. https://www.example.org/xyz/seite1.cgi
Soweit alles klar.
Im Browser wird diese komplex Adresszeile anzeigt.
Und das ist gut so. Dann kann man diese Seite als Lesezeichen ablegen.
Das ist schwierig für die Benutzer.
Woher weißt Du das so genau? Oder ist es Dein persönliches Ästhetikempfinden, das Dich hier fragen lässt? Im Grunde sehen doch Benutzer diese URL überhaupt nicht an. Und bei Bookmarks steht eh der Seitentitel dran.
Geht es - das ich die Startadresse anzeige, am besten auch wenn man sich die Seite als Favorit merkt.
Willst Du, dass die Besucher immer auf der Startseite aufschlagen, auch wenn sie eigentlich eine Unterseite bookmarken wollten? Das wäre aber ein schlechter Umgang mit Deinen Besuchern!
Es gibt die Möglichkeit "schöne" und "sprechende" URLs intern umzuleiten. Beispiel:
http://example.org/impressum leitet intern zu http://example.org/cgi-bin/script.pl?impressum
Zu internen Weiterleitungen findet man etwas unter diesem Begriff: url rewriting.
Liebe Grüße
Felix Riesterer
@@Felix Riesterer
Zu internen Weiterleitungen findet man etwas unter diesem Begriff: url rewriting.
Insbesondere findet man auch When not to use mod_rewrite.
😷 LLAP
Was ist daran schwierig für den Benutzer?
Ist doch gut wenn man der Adresse ansieht wo man sich gerade befindet.
Hallo fiversen,
Geht es - das ich die Startadresse anzeige, am besten auch wenn man sich die Seite als Favorit merkt.
Es gibt Webangebote, die zeigen immer nur https://www.example.org
an und präsentieren dem Anwender die unterschiedlichsten Inhalte. Auf diese Weise verhindern sie Deep Linking, und sie sabotieren auch die Möglichkeit, dass der Nutzer die Vor-/Zurück Navigation des Browsers verwendet.
Solche Verfahren basieren darauf, interne Links oder Webseiten-Buttons mit JavaScript zu behandeln und mit dem Script die neuen Inhalte zu erzeugen. Aus Sicht des Browsers findet dann überhaupt keine Navigation statt. Ich nehme an, dass man durch "geschickten" Einsatz von Cookies, anderen HTTP Headern und Serverlogik ähnliches erreichen kann.
Aber das sollte man nicht tun. Eine Webseite (nicht Website) braucht eine(n) eindeutige(n) URL. Dadurch ist sie verlinkbar, und dadurch kann der Browser auch erkennen, was er wie cachen kann.
Häßliche, technische URLs in "schicke" URLs zu übersetzen benötigt entweder URL Rewriting, wie Felix es ansprach. Dabei sorgt man im Webserver mit einer geeigneten Rewrite Rule dafür, dass aus
https://www.example.org/foo/bar/16
der Aufruf von
start.cgi?controller=foo&aktion=bar&data=16
wird. Ein solches Controller/Action/Data Pattern findet man häufig auf Webseiten, die nach dem MVC-Muster (Model-View-Controller) programmiert wurden. Das start.cgi lädt den geforderten Controller als Modul (das kann bei Anwendung objektorientierter Programmierung eine Klasse sein) und ruft darin die gewünschte Aktion als Funktion auf.
Statt URL Rewriting kann man - einen geeigneten Webserver oder geeignetes Knowhow vorausgesetzt - auch ein HTTP Modul schreiben, dass solche URLs direkt versteht und die entsprechenden Module lädt. ASP.NET von Microsoft macht sowas.
Ich selbst habe sowas auch mal ohne Rewriting mit Apache und PHP gebaut, weil ich - Schande über mich - da noch gar nicht wusste, dass es das gibt. Man kann einem Server nämlich auch sagen, dass er eine Datei ohne Erweiterung als PHP Script deuten soll. Bei Abruf von /foo/bar/17
ruft er dann foo.php
auf und stellt das /bar/17
in der Servervariablen PATH_INFO zur Verfügung. Man sollte dann nur verbieten, dass die normalen User Dateien in den Webspace hochladen können, sonst laden sie eine Datei "dings" hoch und lassen sie als PHP laufen...
Rolf
Lieber Rolf,
Ich selbst habe sowas auch mal ohne Rewriting mit Apache und PHP gebaut,
http://example.org/index.php/was/auch/immer/man/will
Das klappt deshalb so gut, weil der Webserver das PHP-Script ausführt und den Rest ignoriert. Das PHP-Script kann dagegen mit dem Rest gezielt etwas anfagen... wenn man es entsprechend gestaltet.
Liebe Grüße
Felix Riesterer
Lieber Rolf,
Ich selbst habe sowas auch mal ohne Rewriting mit Apache und PHP gebaut,
http://example.org/index.php/was/auch/immer/man/will
Das klappt deshalb so gut, weil der Webserver das PHP-Script ausführt und den Rest ignoriert. Das PHP-Script kann dagegen mit dem Rest gezielt etwas anfagen... wenn man es entsprechend gestaltet.
Das nennt sich dann PathInfo. Und bei richtiger Servereinstellung kann man sich das index.php dann auch schenken.
LG + Gesundheit
Localhorst
Hallo,
Das nennt sich dann PathInfo.
das hat Rolf vor zwei Tagen auch schon erklärt ...
Und bei richtiger Servereinstellung kann man sich das index.php dann auch schenken.
... und das immerhin angedeutet.
Live long and pros healthy,
Martin
Lieber Martin,
das hat Rolf vor zwei Tagen auch schon erklärt ...
ja, er schrieb wörtlich:
Bei Abruf von /foo/bar/17 ruft er dann foo.php auf und stellt das /bar/17 in der Servervariablen PATH_INFO zur Verfügung.
Mit ist nur nicht klar, wann der Webserver (es ist ja auch nicht egal welcher) mit .../foo/... ein PHP-Script mit dem Dateinamen foo.php "versteht" und entsprechend aufruft.
Und bei richtiger Servereinstellung kann man sich das index.php dann auch schenken.
... und das immerhin angedeutet.
Das kommt auch wieder sehr darauf an... ;-)
Liebe Grüße
Felix Riesterer
Hallo Felix,
bei Apache regelt das das mod_negotiation mit der Option multiviews.
Ich finde, dass diese Funktionalität die Zugriffe eher unsicher oder zumindest schwer durchschaubar macht.
LG + Gesundheit
Localhorst
Hallo Felix,
Mit ist nur nicht klar, wann der Webserver (es ist ja auch nicht egal welcher) mit .../foo/... ein PHP-Script mit dem Dateinamen foo.php "versteht" und entsprechend aufruft.
Tjaaa, wenn ich da noch wüsste, was ich da eingestellt habe. Der Server ist mittlerweile offline, und eine lokale .htacces Kopie hab ich nicht. Vielleicht war es MultiViews. Was gar nicht gut ist. Aber damals wusste ich es nicht besser. Heute würde ich das sicherlich mit mod_rewrite lösen. Dann hätte ich auch keinen getrennten Code für meinen lokalen Test mit IIS und den Einsatz auf dem Apache gebraucht (das handhabte sich nicht genau gleich).
Rolf
https://www.example.org/foo/bar/16
der Aufruf von
start.cgi?controller=foo&aktion=bar&data=16
Ich selbst habe sowas auch mal ohne Rewriting mit Apache und PHP gebaut
Wieso nicht ganz einfach ...
ErrorDocument 404 /index.php
in der Serverkonfiguration notieren und die index.php die URL auswerten lassen?
Tach!
Wieso nicht ganz einfach ...
ErrorDocument 404 /index.php
in der Serverkonfiguration notieren und die index.php die URL auswerten lassen?
Die dafür vorgesehene Direktive ist FallbackResource.
dedlfix.
Die dafür vorgesehene Direktive ist FallbackResource.
Dann eben
FallbackResource /index.php
... das spart das Setzen des 200er Headers.
Hallo dedlfix,
Die dafür vorgesehene Direktive ist FallbackResource.
interessant, kannte ich nicht, wurde ja zumeist hier im Forum RewriteEngine empfohlen. Daher ein paar Fragen dazu:
Soweit ich das jetzt mal nachgeschaut habe reicht da eine htaccess mit "FallbackResource /xyz.php" damit man nicht an der Serverconf rumspielen muss?
Und, wenn ich das im obersten Verzeichnis haben, greift das dann auf alle Unterverzeichnisse?
Gibts einen Grund/Vorteil das dennoch besser durch die RewriteEngine zu lösen?
Gruss
Henry
Tach!
- Soweit ich das jetzt mal nachgeschaut habe reicht da eine htaccess mit "FallbackResource /xyz.php" damit man nicht an der Serverconf rumspielen muss?
Wo diese Directive verwendbar ist, steht in der verlinkten Dokumentation.
- Und, wenn ich das im obersten Verzeichnis haben, greift das dann auf alle Unterverzeichnisse?
Das ist das Standardverhalten. Wenn das bei dieser Direktive abweicht, steht das sicher in der Dokumentation.
- Gibts einen Grund/Vorteil das dennoch besser durch die RewriteEngine zu lösen?
Vielleicht. Ich hatte das mal vor langer Zeit probiert, aber irgendwas war da, was ich mir nicht gemerkt habe. Vielleicht ist auch meine Erinnerung falsch.
dedlfix.
Hallo,
- Gibts einen Grund/Vorteil das dennoch besser durch die RewriteEngine zu lösen?
Bei mir funktioniert das Fallback beim Apache so:
wenn die aufgerufene Ressource nicht tatsächlich vorhanden ist, wird der Inhalt der FallbackResource angezeigt, die URL bleibt aber erhalten. Obwohl im Pfad der URL eine index.php liegt und diese auch in in DirectoryIndex angegeben ist, wird diese ignoriert. Explizit aufrufen kann ich sie allerdings.
So ganz durchschaut habe ich die Geschäftsregeln noch nicht...
i2bc
LG + Gesundheit
Localhorst
Hallo localhorst,
ich habe das gleiche Problem.
"example.com/test/index.php" existiert und kann ich aufrufen auch als "example.com/test". Mit "FallbackResource /xyz.php" kann ich "example.com/test" aber nicht mehr aufrufen schleust mich dann weiter zur xyz.php
Gruss
Henry
Hallo,
ich habe das gleiche Problem.
ob das ein Problem ist, ist Ansichtssache. Ich halte es zumindest für nicht ganz durchdacht von den Apache-Entwicklern.
"example.com/test/index.php" existiert und kann ich aufrufen auch als "example.com/test". Mit "FallbackResource /xyz.php" kann ich "example.com/test" aber nicht mehr aufrufen schleust mich dann weiter zur xyz.php
Sieht für mich so aus, als hätte die Direktive FallbackResource Vorrang vor DirectoryIndex. Andersrum wäre es meines Erachtens sinnvoller.
Live long and pros healthy,
Martin
Hallo Raketenwilli,
verwischt das nicht die logische Grenze zwischen URL-Routing und Errorhandling?
Das etwas funktioniert, muss nicht heißen dass das eine gute Praxis ist.
Ich würde es jedenfalls für fragwürdig halten, in index.php prüfen zu müssen, ob der Abruf für eine bekannte oder unbekannte Adresse kam. Bei unbekannten Seiten sollte schließlich eine Fehlerinformation kommen, und sei es auch nur als Einblendung unter dem Seitenheader.
Rolf
verwischt das nicht die logische Grenze zwischen URL-Routing und Errorhandling?
„Ja, klar!“ und zugleich „Nein!“. Letzteres weil diese Grenze bereits durch das Rewriting im genannten Fall ebenso verwischt wird… Man muss/kann/soll ja auch mit einer 404er Fehlermeldung reagieren wenn in
https://www.example.org/foo/bar/16
das „foo“ oder/und das „bar“ oder/und die „16“ unbekannt sind.
Ansonsten waren wir schon bei "FallbackResource" angelangt…
Lieber Jörg,
Wieso nicht ganz einfach ...
ErrorDocument 404 /index.php
"einfach"? Da ist es wieder mein Lieblingsunwort.;-)
In meinen Projekten definiere ich eine echt vorhandene Resource, die ihrerseits aber auch wieder von der Rewrite-Regel erfasst und ausgewertet wird:
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
RewriteEngine on
# reagiere nur auf HTML-Dateien
RewriteCond %{REQUEST_URI} (^/$)|(\.html?$)
# ... da kommt eigentlich noch mehr projektspezifisches
RewriteRule (.*) /index.php?_p=/$1 [QSA]
Die index.php muss dann eben sehen, was da ursprünglich gefordert war ($_SERVER['REQUEST_URI']
) und woher wir tatsächlich kommen (hier $_GET['_p']
).
Liebe Grüße
Felix Riesterer
Hallo,
ich starte meine Seite bei https://www.xxx.de/startseite.html
Da verzweige ich auf ein cgi-script, das die Seite zusammenbaut. https://www.xxx.de/xyz/seite1.cgi
Im Browser wird diese komplex Adresszeile anzeigt.
Das ist schwierig für die Benutzer.
Geht es - das ich die Startadresse anzeige, am besten auch wenn man sich die Seite als Favorit merkt.
Das kann mit einer Servereinstellung erreicht wetden.
Beim Apache z. B. sorgt die Einstellhng DirectoryIndex für den Aufruf eines "Startskriptes", wenn keine Ressource angegeben wurde, sondern nur der Pfad dorthin.
LG + Gesundheit
Localhorst
Hallo,
vielen Dank für die Antworten.
Ich sehe ein - transparent ist es nur wenn die Adresse auch wirklich das aktive File darstellt.
Die Lösungen - soweit ich die nachvollzogen habe, machen es komfortabel von einer Seite zur nächsten zu wechseln.... Aber die Address-Anzeige ist dann ja immer noch 'kompliziert'. Jetzt haben die Nutzer teilweise 'startseite.html' und teilweise das 'seite1.cgi' als Favorit sich gemerkt.
ich hätte den Output des Scripts als html-file gespeichert. Diese Seite dann dorthin kopiert mit einen ansprechenden Namen. Und das wäre dann stabil.
Dann hätte meine 'startseite.html' immer einen aktuellen Inhalt, bei gleichbleibender Adresse.
Und die alte script-seite 'seite1.cgi' verweist nur auf die 'startseite.html'.
-- Frank I.
Hallo fiversen,
die Ausgabe eines CGI als statisches HTML zu speichern kann sich lohnen, wenn das CGI aufwändig ist und den Server stark belastet. Das wäre dann eine Form des Cachings.
Aber nur wegen der URL? Nein. Das macht man definitiv anders, und Möglichkeiten dafür wurden Dir vorgestellt. Man muss dafür allerdings in die Serverkonfiguration eingreifen, um den Rewrite zu bekommen.
Falls Du keine Rewrites einrichten darfst, aber SSI benutzen kannst: Du könntest in startseite.html ein <!-- #include virtual="/xyz/seite1.cgi" --> einsetzen, und der Server würde dann die Ausgabe des CGI liefern.
Oder Du verwendest startseite.php statt html und lädst aus dem PHP Script heraus den Output des CGI. Möglichkeiten gibt's viele. Statisches Speichern sollte auf Platz 99 der Liste stehen.
Rolf
Ich darf nochmals fragen
Aber die Address-Anzeige ist dann ja immer noch 'kompliziert'.
Was ist daran wie kompliziert?
Jetzt haben die Nutzer teilweise 'startseite.html' und teilweise das 'seite1.cgi' als Favorit sich gemerkt.
Leite von der alten Seite zur neuen um. Bring auf der alten einen Hinweis dass es diese Seite nicht mehr lange geben wird und man seinen Favoriten ändern soll. Mit Link auf die neue Seite. Das ist lästig und bewegt die Nutzer zum umstellen.
Hallo,
Ich darf nochmals fragen
Aber die Address-Anzeige ist dann ja immer noch 'kompliziert'.
Was ist daran wie kompliziert?
ich finde: Gar nichts.
Im Gegenteil. Wenn ich als Ortsfremder einen Passanten frage, wo ich hier gerade bin, und der sagt mir: "In Neustadt", dann hilft mir das wenig. Nützlicher ist da schon, wenn er sagt: "Ecke Lange Straße und Rathausgasse".
Zurück auf das URL-Beispiel übertragen bedeutet das: Wenn man überhaupt etwas weglassen (nicht anzeigen) möchte, dann eher den Hostnamen als den Local-Part.
Jetzt haben die Nutzer teilweise 'startseite.html' und teilweise das 'seite1.cgi' als Favorit sich gemerkt.
Leite von der alten Seite zur neuen um.
Ja.
Bring auf der alten einen Hinweis dass es diese Seite nicht mehr lange geben wird und man seinen Favoriten ändern soll. Mit Link auf die neue Seite.
Diesen Hinweis sieht aber niemand mehr, wenn man von der alten auf die neue Seite umleitet. Muss auch nicht, wenn die Umleitung als solche dauerhaft bestehen bleibt.
Das ist lästig
Findest du?
Live long and pros healthy,
Martin