nicht angemeldet
Karl Heinz
TS
Karl Heinz
TS
Karl Heinz
Auge
Der Martin
TS
Hallo,
ich habe eine Frage zu URL-Parametern.
Ich werde es anhand eines Beispiels erklären.
Ausgangs-URL ist folgende:
Ausgangs-URL wird per 301 weitergeleitet auf:
https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
Ich möchte nun herausfinden, ob URL Parameter bei der Weiterleitung korrekt übergeben werden. Muss ich die Ausgangs-URL dann
so (mit Slash vor dem ?)
oder so (ohne Slash vor dem ?)
erweitern, oder sind beide Varianten OK?
Die Variante mit Slash gibt mir eine 404 zurück. Habt ihr eine Ahnung warum?
Die Variante ohne Slash führt die Weiterleitung durch, allerdings geht der URL-Parameter verloren. Wie kann ich erreichen, dass der URL-Parameter mit an die neue URL übermittelt wird. Ist das eine Einstellung von regulären Ausdrücken in der htaccess-Datei?
Hallo und guten Morgen,
Die Variante mit Slash gibt mir eine 404 zurück. Habt ihr eine Ahnung warum?
Weil die Ressource nicht vorhanden ist?
Wie lauten denn deine Regeln für mod_rewrite?
Die Variante ohne Slash führt die Weiterleitung durch, allerdings geht der URL-Parameter verloren. Wie kann ich erreichen, dass der URL-Parameter mit an die neue URL übermittelt wird. Ist das eine Einstellung von regulären Ausdrücken in der htaccess-Datei?
versuch es mal mit einem angehängten [QSA], also z. B.
RewriteRule (.*) index.php/$1 [QSA]
Grüße
TS
Die Variante mit Slash gibt mir eine 404 zurück. Habt ihr eine Ahnung warum?
Weil die Ressource nicht vorhanden ist?
Ich habe die Seite ja nicht erstellt. Eine guter Programmierer würde die Ressource sowohl bei der "mit Slash" Variante als auch bei der "ohne Slash" Variante zu Verfügung stellen, sprich die Weiterleitung würde bei beiden Varinaten funktionieren ohne das es eine 404 gibt. Liege ich da richtig?
Bisher dachte ich immer man hängt vor das ? des URL-Parameters grundsätzlich einen Slash. Ist das nicht so? Wenn nein warum nicht?
Wie lauten denn deine Regeln für mod_rewrite?
Kann ich Dir nicht sagen, hab die Seite nicht programmiert und auch keinen Zugriff auf ftp, Hoster usw. Ich habe Probleme mit Google Analytics, weil die Programamierer etwas bezogen auf die Weiterleitungen falsch gemacht haben. Ich muss zunächst im Detail verstehen was falsch ist, dann kann ich den Programmierern auch erklären was Sie ändern sollen. Deshalb die Fragen an Euch :-).
Die Variante ohne Slash führt die Weiterleitung durch, allerdings geht der URL-Parameter verloren. Wie kann ich erreichen, dass der URL-Parameter mit an die neue URL übermittelt wird. Ist das eine Einstellung von regulären Ausdrücken in der htaccess-Datei?
versuch es mal mit einem angehängten [QSA], also z. B.
RewriteRule (.*) index.php/$1 [QSA]
Danke für den Tipp :-). Gebe ich so weiter.
Hallo und guten Morgen,
Ich habe die Seite ja nicht erstellt. Eine guter Programmierer würde die Ressource sowohl bei der "mit Slash" Variante als auch bei der "ohne Slash" Variante zu Verfügung stellen, sprich die Weiterleitung würde bei beiden Varinaten funktionieren ohne das es eine 404 gibt. Liege ich da richtig?
Nicht unbedingt. Mal generisch betrachtet, also ohne Weiterleitung/Umleitung, bedeutet die Variante mit dem abschließenden Slash, dass es ich um einen Pfad handelt, in dem die Ressource zu finden ist. Die Ressource selber ist nicht angegeben. Der Webserver entscheidet, welche er nun auszuliefern gedenkt. Beim Apache wird das durch die Einstellung "DirectoryIndex" bestimmt.
Wenn Du aber am Ende ~~~/ressource.html stehen hast, dann bedeutet das, dass Du die Ressoruce exakt spezifiziert hast. Sie müsste dann (erst einmal) auch vorhanden sein, sonst gibt es einen Status 404 als Antwort.
Nun kann man mehrere Dinge hinzunehmen:
Bei Mod Rewrite gibst Du vor, was wohin umgeleitet werden soll (sichtbar für den Browser) oder was stattdessen ausgeliefert werden soll (serverintern, nicht sichtbar für den Browser).
Bei Content Negotiation sucht der Server eigenständig nach einer Ressource, die genau passt, am besten passt, oder so ähnlich lautet. Da frag mal @Gunnar, das war mal eines seiner Lieblingsthemen.
Bisher dachte ich immer man hängt vor das ? des URL-Parameters grundsätzlich einen Slash. Ist das nicht so? Wenn nein warum nicht?
Nein, siehe oben.
Grüße
TS
Das heißt die URL Parameter funktionieren sowohl mit als auch ohne / vor dem ?.
Dann verstehe ich aber nicht, warum in den Anleitungen immer mit / gearbeitet wird.
Siehe z.B. hier:
https://wiki.selfhtml.org/wiki/Glossar:URL-Parameter
Mann könnte vermuten, dass das / immer verpflichtend ist.
Hallo
Das heißt die URL Parameter funktionieren sowohl mit als auch ohne / vor dem ?.
Es kommt darauf an. TS schrieb (Hervorhebung von mir):
generisch betrachtet … bedeutet die Variante mit dem abschließenden Slash, dass es ich um einen Pfad handelt, in dem die Ressource zu finden ist. Die Ressource selber ist nicht angegeben. Der Webserver entscheidet, welche er nun auszuliefern gedenkt.
Wenn es in dem angegebenen Pfad eine „index.html“ oder eine „default.php“ gibt und der Webserver per Konfiguration weiß, dass er bei Aufruf von „example.com/verzeichnis/“ eine dort evetnuell vorhandene „index.html“ oder „default.php“ ausliefern soll, wird er das tun. Eine Datei/Ressource, die in der Konfiguration nicht angegeben ist, wird er ohne die explizite Angabe ihres Namens nicht herausrücken.
Tschö, Auge
Hallo,
Das heißt die URL Parameter funktionieren sowohl mit als auch ohne / vor dem ?.
das eine hat mit dem anderen nichts zu tun. Erst mal ein Beispiel ohne URL-Parameter:
Angenommen, im Server-Verzeichnis /foo liegt ein HTML-Dokument bar.html. Das kannst du also über http://example.org/foo/bar.html abrufen. Versuchst du es aber mit http://example.org/foo/bar.html/, dann kassierst du einen 404er-Error, weil der Server dann im Verzeichnis /foo/bar.html/ nach dem Standard-Dokument (z.B. index.html) sucht. Das schlägt fehl, weil bar.html eben nicht als Verzeichnis ansprechbar ist.
Dann verstehe ich aber nicht, warum in den Anleitungen immer mit / gearbeitet wird.
Weil man oft nur das Standard.Dokument im Verzeichnis adressieren will, und sich die Angabe index.html oder index.php sparen will. Die ergänzt der Server schon von sich aus.
https://wiki.selfhtml.org/wiki/Glossar:URL-Parameter
Mann könnte vermuten, dass das / immer verpflichtend ist.
Das ist ein Irrtum. Das liegt nur daran, dass in allen Beispielen nur die explizit-namentliche Angabe des Dokuments weggelassen wurde.
So long,
Martin
Hallo und guten Tag,
Das heißt die URL Parameter funktionieren sowohl mit als auch ohne / vor dem ?.
Die URL-Parameter haben mit der Ressource erstmal nichts zu tun. Sie werden ihr üblicherweise übergeben zur weiteren Berücksichtigung. Dazu muss die Ressource aber erst einmal bestimmt werden können vom Webserver. Und dafür macht der abschließende Slash eben doch einen Untrerschied.
Wenn Du nur die Domain angibst
http://example.org
kann der Webserver damit eigentlich nichts anfangen, denn die Domain ist keine Ressource, sie enthält welche. Darum ergänzt der Webserver an dieser Stelle ausnahmsweise (weil er eben so programmiert und eingestellt ist) den Request
http://example.org/
und sendet diesen String an den Browser zurück, mit der bitte, es doch dort zu versuchen. Das kannst Du in der Adressleiste wunderbar beobachten und wenn Du eine HTTP-Header-Extension hast, müsstest Du es auch dort sehen können.
Wenn dann http://example.org/ beim Server ankommt als Request, ist immer noch keine Ressource angegeben, aber der Server weiß nun (beim Apachen), dass er entsprechend der DirectoryIndex-Einstellung nach einer suchen soll. Das ist dann i. d. R. eine index.html oder index.php oder so ähnlich. man kann aber auch jede andere Datei dort angeben.
Hast Du einen Arbeitsplatz-Webserver zur Verfügung, z. B. XAMPP? Dann kannst Du das alles wunderbar ausprobieren. Bau dir dort verschiedene Virtual Hosts auf mit unterschiedlichsten Einstellungen, trage sie in deinen DNS oder deine lokale Hosts-Datei ein. Dann kannst Du schnell, einfach und wunderbar vergleichen, wie sich unterschiedliche Einstellugnen und Rahmenbedingungn auswirken.
Und glaub mir, diese Übung lohnt sich, wenn Du Webentwicklung betreiben willst.
Mann könnte vermuten, dass das / immer verpflichtend ist.
Ja, ist es eigentlich direkt hinter der Domainangabe.
Grüße
TS
Hallo,
Wenn Du nur die Domain angibst
http://example.orgkann der Webserver damit eigentlich nichts anfangen, denn die Domain ist keine Ressource, sie enthält welche. Darum ergänzt der Webserver an dieser Stelle ausnahmsweise (weil er eben so programmiert und eingestellt ist) den Request
http://example.org/und sendet diesen String an den Browser zurück, mit der bitte, es doch dort zu versuchen.
das beschriebene Verhalten ist so richtig, aber ausgerechnet nicht in dem Fall, den du als Beispiel gewählt hast. Gibt man nur den Domainnamen in die Adresszeile ein (oder als Linkziel), also http://example.org, dann ergänzt der Client den abschließenden Slash bereits, weil es sonst keinen syntaktisch korrekten HTTP-Request ergibt.
Das kannst Du in der Adressleiste wunderbar beobachten und wenn Du eine HTTP-Header-Extension hast, müsstest Du es auch dort sehen können.
Ja, in anderen Fällen, also nicht Document Root, ist das so. Da gibt der Server ein Redirect auf die Variante mit abschließendem Slash.
Ciao,
Martin
Hallo Martin,
das beschriebene Verhalten ist so richtig, aber ausgerechnet nicht in dem Fall, den du als Beispiel gewählt hast. Gibt man nur den Domainnamen in die Adresszeile ein (oder als Linkziel), also http://example.org, dann ergänzt der Client den abschließenden Slash bereits, weil es sonst keinen syntaktisch korrekten HTTP-Request ergibt.
Das habe ich eben auch gerade gesehen. Ich sollte die Übungen von Zeit zu Zeit also auch selber mal wiederholen ;-)
Im (guten alten)™ IE 8.0 ist es aber noch so, dass es dem Benutzer auch angezeigt wird.
Im FF ist es auch noch so (siehe http-header), aber es wird dem User einfach nicht mehr angezeigt...
Grüße
TS
Hi,
Im (guten alten)™ IE 8.0 ist es aber noch so, dass es dem Benutzer auch angezeigt wird.
Im FF ist es auch noch so (siehe http-header), aber es wird dem User einfach nicht mehr angezeigt...
ich verstehe zwar nicht genau, was du damit sagen willst ... aber AFAIR verstümmelt der Firefox die Adresszeile in der Defaulteinstellung sowieso ein bisschen. Das Protokoll-Präfix http:// oder https:// lässt er einfach weg, wenn mich nicht alles täuscht, und URL-Parameter werden teilweise auch nicht angezeigt.
Das ist bei einer Firefox-Installation oder einem Customizing eine der zahlreichen Einstellungen, die ich erstmal in Ordnung bringe: In about:config ...
Harzliche Grüße,
Martin
Hallo Martin,
Das ist bei einer Firefox-Installation oder einem Customizing eine der zahlreichen Einstellungen, die ich erstmal in Ordnung bringe: In about:config ...
- browser.urlbar.formatting.enabled auf false setzen, damit nicht Teile der Adresse in hellgrau gesetzt werden,
- browser.urlbar.trimURLs auf false setzen, damit nicht Teile der Adresse in der Anzeige einfach weggelassen werden.
Guter Tipp. Fang doch gleich mal einen WIKI-Artikel zu slchen Browser- und Einstellugnstipps an. Da kommen dann bestimmt noch ganz viele dazu, auch für AddOns, PlugIns und den ganzen Quatsch...
Zurück zum Thema:
Und wenn man genau hinsieht, wird als erste Ressource ohnehin "example.org/favivon.ico" gesucht vom Browser, egal ob man das haben will, oder nicht.
Grüße
TS
Zurück zum Thema:
Und wenn man genau hinsieht, wird als erste Ressource ohnehin "example.org/favivon.ico" gesucht vom Browser, egal ob man das haben will, oder nicht.
Wieso? Wer benutzt denn einen Browser, der das favicon im Tab anzeigt? Insoweit bist Du doch sehr wohl derjenige, der das Favicon sehen und also abholen lassen "will"...
(Ich weiß: Du hast keine Alternative...)
Hallo
Das ist bei einer Firefox-Installation oder einem Customizing eine der zahlreichen Einstellungen, die ich erstmal in Ordnung bringe: In about:config ...
- browser.urlbar.formatting.enabled auf false setzen, damit nicht Teile der Adresse in hellgrau gesetzt werden,
Auch wenn der ausgegraute Teil der URL in der Adresszeile für mich noch gut lesbar ist, ist das eine Erleichterung, danke.
- browser.urlbar.trimURLs auf false setzen, damit nicht Teile der Adresse in der Anzeige einfach weggelassen werden.
Kannte und hatte ich schon.
Dabei ist mir die Einstellung browser.urlbar.suggest.history.onlyTyped unter die Nase gekommen. Hat sie den Wert true bietet die Adresszeile als Autovervollständigungsvorschläge nur URLs an, die man selbst irgendwann mal händisch eingegeben hat. Mit dem Wert false wird mir (gefühlt) jede teilweise passende URL angeboten, die ich jemals aufgerufen habe.
In der Mozilla-Suite konnte man das ehedem auch im Einstellungsdialog festlegen, beim Firefox fiel es weg. Ich habe mir das eins-zwei-fix auf true gestellt und genieße jetzt ein aufgeräumtes Angebot von Vorschlägen. :-)
Tschö, Auge
Hallo und guten Tag,
Dabei ist mir die Einstellung browser.urlbar.suggest.history.onlyTyped unter die Nase gekommen. Hat sie den Wert true bietet die Adresszeile als Autovervollständigungsvorschläge nur URLs an, die man selbst irgendwann mal händisch eingegeben hat. Mit dem Wert false wird mir (gefühlt) jede teilweise passende URL angeboten, die ich jemals aufgerufen habe.
Das wird ja immer spannender hier. Ich sag doch, alles ins Wiki ;-)
Grüße
TS
Hallo
Dabei ist mir die Einstellung browser.urlbar.suggest.history.onlyTyped unter die Nase gekommen. Hat sie den Wert true bietet die Adresszeile als Autovervollständigungsvorschläge nur URLs an, die man selbst irgendwann mal händisch eingegeben hat. Mit dem Wert false wird mir (gefühlt) jede teilweise passende URL angeboten, die ich jemals aufgerufen habe.
Das wird ja immer spannender hier. Ich sag doch, alles ins Wiki ;-)
Da hast du noch 'was zum plündern. Vieles davon ist recht spezifisch für die Sperrung von Funktionen und Einstellungen an öffentlich zugänglichen Rechnern, manche Einstellung wird aber vermutlich auch allgemein von Interesse sein.
Tschö, Auge
Hallo
Das wird ja immer spannender hier. Ich sag doch, alles ins Wiki ;-)
Kurzer Einwurf, da es mir soeben auf Heise.de unter die Nase kam.
Der Firefox bietet über die Battery Status API Zugriff auf den Ladezustand, den Typ, die Kapazität und weitere Infos zum Akku. Vom W3C wurde das – laut dem Heise-Artikel – eingeführt, damit Websitebetrieber anhand des aktuellen Ladezustands entscheiden können, Funktionen, die am Akku ziehen, eventuell nicht einzuschalten.
Da die Funktion, wie z.B. auch die Liste der installierten Schriftarten, aber auch dazu genutzt werden kann, die Gerät-Browser-Kombination wiederzuerkennen, wird die API ab der Firefox-Version 52 wieder entfernt. Abschalten kann man sie, wie der Heise-Artikel beschreibt, aber jetzt schon. In der about:config nach dom.battery.enabled suchen und auf FALSE setzen.
Chromium bietet ebenfalls Zugang zu der API. Ob der Zugriff dort abschaltbar ist, weiß ich nicht.
Tschö, Auge
und URL-Parameter werden teilweise auch nicht angezeigt.
wird ja auf
https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
weitergeleitet.
Packe ich hinter die erste URL einen URL-Parameter so wird dieser, so wie sich das sehe, nicht an die zweite URL weitergeleitet.
Kann es sein, dass die Weiterleitung schon funktioniert, dass die URL Parameter im Firefox nur nicht angezeigt werden. So wie von Dir oben erwähnt?
Hallo und guten Tag,
und URL-Parameter werden teilweise auch nicht angezeigt.
wird ja auf
https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
weitergeleitet.
Packe ich hinter die erste URL einen URL-Parameter so wird dieser, so wie sich das sehe, nicht an die zweite URL weitergeleitet.
Kann es sein, dass die Weiterleitung schon funktioniert, dass die URL Parameter im Firefox nur nicht angezeigt werden. So wie von Dir oben erwähnt?
Das kannst Du nur auf dem Server wirklich beantworten. Dazu müsstest Du einen Zugriff dazu haben.
Was der Browser aktuell anzeigt, ist Makulatur, wie Du aus der Disskussion dieses Threads erkennen solltest! Jeder Browser kann anders eingestellt sein und anders reagieren.
Du kannst ggf. ein Test-Szenario aufbauen, wenn Du dir einen lokalen Webserver (auf dem Client-Host) einrichtest und Requests dann auf den lokalen Webserver umleitest.
Aber zuerst würde ich alle Daten (Parameter und Vorgaben, Scheme, ...) sichtbar machen, so wie das hier gemeinschaftlich erarbeitet wurde.
Die Äußerung deiner Ideen kann durchaus zielführend sein, aber meistens sollte man erst eine gemeinsame Basis herstellen. Also folge bitte auch den Hinweisen von Martin und Auge zu den Browsereinstellungen. "Moderne Software" entmündigt den Nutzer meistens. Soweit dies möglich ist, müssen wir für uns unbedingt diese Entmündigungen rückgängig machen!
Grüße
TS
Kann es sein, dass die Weiterleitung schon funktioniert, dass die URL Parameter im Firefox nur nicht angezeigt werden. So wie von Dir oben erwähnt?
NEIN! Aber das hättest Du mit den Entwicklerwerkzeugen auch sehen können. 'nur nicht angezeigt' issnich - und zwar aus Sicherheitsgründen.
Wenn vermittels Javascript mit document.href='addr' oder window.href='addr' die URI umgeschrieben wird, dann geht der Browser auch dorthin.
Hier der relevante Ausschnitt der gesendeten header:
HTTP/1.1 301 Moved Permanently
...
Location: https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
Aufgerufen mit
wget -d --delete-after https://www.nettofox.ch/Heizung/Fussbodenheizung/Fussbodenheizungverteiler/Messingverteiler-1-verchromt-inklusive-Taconova-Topmeter.html
Hint: wget gibt es auch für Windows...
Hi,
wird ja auf
https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
weitergeleitet.
Packe ich hinter die erste URL einen URL-Parameter so wird dieser, so wie sich das sehe, nicht an die zweite URL weitergeleitet.
Kann es sein, dass die Weiterleitung schon funktioniert, dass die URL Parameter im Firefox nur nicht angezeigt werden. So wie von Dir oben erwähnt?
nein, die URL-Parameter gehen wegen einer Schlamperei in der Serverkonfiguration verloren. Der Server sollte sie bei seinem Umleitungszeil, das er dem Client anbietet, eigentlich wieder mit anhängen. Tut er aber offensichtlich nicht.
Ciao,
Martin
nein, die URL-Parameter gehen wegen einer Schlamperei in der Serverkonfiguration verloren.
Naja. Ich vermute einen "SEO-Experte", der erst die künstlichen URL mit ganz viel Messing, Verteiler, Fussboden und Heizung gebaut hat, dann wegen des duplicated content kalte Füße bekam.
Hallo und guten Abend,
wird ja auf
https://www.nettofox.ch/messingverteiler-1-verchromt-inklusive-taconova-topmeter.html
weitergeleitet.
Packe ich hinter die erste URL einen URL-Parameter so wird dieser, so wie sich das sehe, nicht an die zweite URL weitergeleitet.
Kann es sein, dass die Weiterleitung schon funktioniert, dass die URL Parameter im Firefox nur nicht angezeigt werden. So wie von Dir oben erwähnt?
nein, die URL-Parameter gehen wegen einer Schlamperei in der Serverkonfiguration verloren. Der Server sollte sie bei seinem Umleitungszeil, das er dem Client anbietet, eigentlich wieder mit anhängen. Tut er aber offensichtlich nicht.
Steiche: Schlamperei
Setze: Willkür
Das ist kein Versehen, sondern muss als Absicht ausgelegt werden! Wer einen Server betreibt und konfiguriert, sollte zumindest bei Verbiegungen kontrollieren, was er treibt.
Ok, das weiß vermutlich niemand, der "mal eben schnell" ein paar Rewrite-Rules in seine .htaccess schreibt. Aber genau DAS ist doch unsere Aufgabe als Regulars: die Möglichkeiten und Fallstricke möglichst strukturiert kommunizieren! Wir haben das vermutlich selber alles mal falsch angepackt, wenn wir es nicht heute noch tun in irgendwelchen vergrabenen Domains...
Grüße
TS
Wenn Du nur die Domain angibst
http://example.orgkann der Webserver damit eigentlich nichts anfangen, denn die Domain ist keine Ressource, sie enthält welche. Darum ergänzt der Webserver an dieser Stelle ausnahmsweise (weil er eben so programmiert und eingestellt ist) den Request
http://example.org/und sendet diesen String an den Browser zurück, mit der bitte, es doch dort zu versuchen.
Das passiert dann automatisch oder? Sprich wenn ich / weglasse bekommt der Browser vom Server die kryptische Meldung, dass er / dazu packen soll. Das macht der Browser dann automatisch und schwups wird die Seite geladen? Oder bekommt der Nutzer die Meldung, das er / dazu packen soll?
Falls ja verwirrt mich das. TS hatte doch geschrieben wenn kein / da ist dann liefert der Server automatisch (je nach Konfiguration) die Default Datei (z.B. index.php) zurück? Das wäre ja ein Wiederspruch zu dem was du schreibst.
das beschriebene Verhalten ist so richtig, aber ausgerechnet nicht in dem Fall, den du als Beispiel gewählt hast.
Ich verstehe leider nicht was du meinst, kannst du das etwas genauer erklären. Gebe ich
im Browser ein, so werde ich auf eine andere Seite weitergeleitet, die hat aber am Ende kein / demnach hat der Server das / eben nicht dazu gepackt.
Hallo und guten Morgen,
Das passiert dann automatisch oder? Sprich wenn ich / weglasse bekommt der Browser vom Server die kryptische Meldung, dass er / dazu packen soll. Das macht der Browser dann automatisch und schwups wird die Seite geladen? Oder bekommt der Nutzer die Meldung, das er / dazu packen soll?
Er sollte eine Antwort vom Server bekommen, die z. B.
Grüße
TS
Hallo,
Das passiert dann automatisch oder? Sprich wenn ich / weglasse bekommt der Browser vom Server die kryptische Meldung, dass er / dazu packen soll. Das macht der Browser dann automatisch und schwups wird die Seite geladen?
ja, das geht alles vollaitomatisch. Nur die Art und Weise, wie es abläuft, unterscheidet sich danach, ob ich nur http://example.org angegeben habe oder http://example.org/foo.
Fall 1: http://example.org
Der Browser erkennt schon beim Analysieren dieser Adressangabe, dass sie unvollständig ist. Sie enthält nämlich keinen Dokument- oderRessourcennamen. Der ist aber in einem HTTP-Request zwingend erforderlich, denn die erste Zeile eines Requests ist z.B.
GET <ressource> HTTP/1.1
Also ergänzt der Browser völlig selbständig den Slash am Ende und kann damit
GET / HTTP/1.1
bilden. Das ist dann ein gültiger Request.
Fall 2: http://example.org/foo
Hier erkennt der Browser /foo als Dokument- oder Ressourcenbezeichner und kann damit sofort einen ordentlichen HTTP-Request konstruieren:
GET /foo HTTP/1.1
Nun fällt der Server darüber her und schaut nach, ob /foo ein Dokument ist, das er ausliefern kann. Existiert ein solches, liefert er es dem Client ohne Umschweife. Existiert jedoch ein Verzeichnis /foo, dann sendet der Server ein Redirect, also eine Aufforderung an den Client, die in etwa bedeutet "Versuch's nochmal unter http://example.org/foo/". Beachte den Slash, der an der Alternativ-Empfehlung angehängt wurde. Der Browser kommt dieser Aufforderung normalerweise ohne Rückfrage nach und setzt einen zweiten Request ab. Dabei korrigiert er auch die Schreibweise der Adresse in der URL-Zeile.
Oder bekommt der Nutzer die Meldung, das er / dazu packen soll?
Nein. Das wäre für Nutzer, die die Technik nicht kennen (also die allermeisten), nicht sinnvoll.
Falls ja verwirrt mich das. TS hatte doch geschrieben wenn kein / da ist dann liefert der Server automatisch (je nach Konfiguration) die Default Datei (z.B. index.php) zurück? Das wäre ja ein Wiederspruch zu dem was du schreibst.
Nein. Stellt der Server beim Analysieren des Requests fest, dass die angeforderte Ressource eigentlich ein Verzeichnis ist, dann ergänzt er intern den Namen des Standarddokuments. Das ist meistens sowas wie index.html oder index.php oder so. Davon bekommt der Browser aber nichts mit.
So long,
Martin