nicht angemeldet
Datei-URLs mit / am Ende - statt 404-Fehler funktioniert's..?!
Hallo,
der Apache-1.3.26-Server meines Hosters zeigt eine sehr merkwürdige Eigenschaft: URLs, die mit einem Schrägstrich enden, werden ohne Murren ausgeliefert anstatt in einem 404-Fehler zu enden. Bei diesen URLs geht es wohlgemerkt nicht um Verzeichnisse, sondern um Dateien, zum Beispiel:
http://kino-fahrplan.de/kinos/grindel/index.shtml/
Hat jemand eine Idee, wie sowas zustande kommt? Mein Rechner hier unterm Tisch zeigt dieses Verhalten nicht. Gleiches System, gleiche Serverversion, gleiche Module (mit Ausnahme von SSL), ziemlich wahrscheinlich auch die gleiche Konfiguration (fragt mich nicht, woher ich das weiß:).
Es liegt definitiv nicht an mod_negotiation (Multiviews). An meinen weiteren Einstellungen (rewrite, redirect, gzip) kann's auch nicht liegen; das Problem ist auch da, wenn ich die .htaccess lösche.
Ziemlich ratlose Grüße,
soenk.e
-
Huhu Sönke
habe das eben mal ausprobiert und bin auf ein weiteres seltsames Verhalten gestossen.
Wenn ich eine Datei folgendermassen aufrufe
http://www.meineseite.de/huhu/index.php
ist alles wie immer (lädt ca. 90 KB)
aber mit Slash also
http://www.meineseite.de/huhu/index.php/
scheint der Server in irgendeinem Loop gefangen zu sein
die Opera-Ladeanzeige läuft und läuft und läuft ....
über eineinhalb Minuten lang bis ca. 1 MB dann erst ist die Seite da.
ratlose Grüße
lulu
-
Hallo,
in </?m=114101&t=20333> hatte ich sowas geschrieben, das lag aber daran, daß ich auf der Arbeit mit NN 4.7 unterwegs war. Dieser hat ja so einen (extrem nervigen) Bug, daß er, wenn er eine in der Seite referenzierte Datei (wie externes Javascript oder CSS) nicht findet, die 404-Seite anzeigt. Das war dann dadurch zu erklären, daß die URL-Basis für das Stylesheet sich wegen des angefügten / verschoben hatte.
Wie ich sehe, hast Du das Stylesheet inzwischen absolut referenziert, aber es bleibt das Problem mit den relativen Links.Mein Apache 1.3.26 zuhause zeigt dieses Verhalten aber auch...
Schönen Gruß aus Bilk
Rainer
-
in </?m=114101&t=20333> hatte ich sowas geschrieben, das lag aber daran, daß ich auf der Arbeit mit NN 4.7 unterwegs war. Dieser hat ja so einen (extrem nervigen) Bug, daß er, wenn er eine in der Seite referenzierte Datei (wie externes Javascript oder CSS) nicht findet, die 404-Seite anzeigt. Das war dann dadurch zu erklären, daß die URL-Basis für das Stylesheet sich wegen des angefügten / verschoben hatte.
Meiner Meinung nach ist es schlichtweg ein Fehler, wenn der Server auf die Anfrage datei.html/ datei.html ausliefert, denn datei.html/ bezieht sich schließlich auf ein Verzeichnis, also eher auf datei.html/index.html oder ähnliches.
Mein Apache 1.3.26 zuhause zeigt dieses Verhalten aber auch...
Könntest Du mir bitte mal Deine .htaccess schicken (Adresse findet Du unter dem Link oben), damit ich das mit meiner vergleichen kann? Mal abgesehen davon, daß ich dieses Verhalten ansich schon suspekt finde, ist mir auch absolut schleiferhaft, warum es hier bei mir anders läuft (mit Fehler) als bei meinem Hoster und Dir (ohne Fehler).
Ich habe keine Ahnung, welche Einstellung dafür verantwortlich sein könnte, weder negotiation noch spelling sind da im Spiel. Und da es bei mir wie erwartet einen Fehler gibt, kann ich das auch nicht mit irgendwelchen Codeschnüffeleien nachvollziehen.Gruß,
soenk.e-
Meiner Meinung nach ist es schlichtweg ein Fehler, wenn der Server auf die Anfrage datei.html/ datei.html ausliefert, denn datei.html/ bezieht sich schließlich auf ein Verzeichnis, also eher auf datei.html/index.html oder ähnliches.
Einspruch, Euer Ehren ! ;-)
Kennst Du solche URLs ?
http://www.example.com/cgi-bin/demo.cgi/extra/path/info?abc=123
^^^^^^^^^^^^^^^^Das CGI demo.cgi wird mit PATH_INFO=/extra/path/info aufgerufen.
Du benutzt Server Side Includes, und die können den Trick eben auch. Sprich: Du baust so eine URL ...
http://www.example.com/blabla/demo.shtml/extra/path/info?abc=123
^^^^^^^^^^^^^^^^... und kannst dann innerhalb der SHTML-Datei auf PATH_INFO (und PATH_TRANSLATED) zugreifen.
It's not a bug, it's a feature. Und ich mag es, denn man kann damit die verrücktesten Sachen basteln (und sei es nur ein verstecktes CGI).
Mein Apache 1.3.26 zuhause zeigt dieses Verhalten aber auch...
Mein 1.3.14, nebenbei bemerkt, auch. Bei *.html aber definitiv nicht, denn da würde es keinen Sinn machen. HTML ist statisch, SHTML und CGI sind dynamisch. "XBitHack" ist bei mir "off", damit nicht jede HTML-Seite durch die SSI-Engine gedrückt wird.
Alexander
-
Meiner Meinung nach ist es schlichtweg ein Fehler, wenn der Server auf die Anfrage datei.html/ datei.html ausliefert, denn datei.html/ bezieht sich schließlich auf ein Verzeichnis, also eher auf datei.html/index.html oder ähnliches.
Einspruch, Euer Ehren ! ;-)
Kennst Du solche URLs ?
http://www.example.com/cgi-bin/demo.cgi/extra/path/info?abc=123
^^^^^^^^^^^^^^^^Das CGI demo.cgi wird mit PATH_INFO=/extra/path/info aufgerufen.
Oha, Wunder der Technik :)
It's not a bug, it's a feature. Und ich mag es, denn man kann damit die verrücktesten Sachen basteln (und sei es nur ein verstecktes CGI).
Urgs. Man lernt nie aus, danke! Das ist aber ein reichlich hinterhältiges Feature; bei relativen Adressen in so einer Seite bauen die Browser logischerweise Mist (was mich an der ganzen Sache dann auch gestört hat) - und wenn man nicht auf sowas vorbereitet ist.. ;]
Mein 1.3.14, nebenbei bemerkt, auch. Bei *.html aber definitiv nicht, denn da würde es keinen Sinn machen.
Stimmt, bei .shtml und .php geht's mit /, bei .html kommt stattdessen tatsächlich der "erhoffte" 404. Da habe ich mir heute beim Rumprobieren wahrscheinlich selbst ein Bein gestellt, denn die einzigen Dateien, die hier auf .html enden, liegen ausgerechnet in einem Verzeichnis, in dem mod_rewrite bestimmte Adressen umbiegt..
Gruß,
soenk.e-
Hi,
http://www.example.com/cgi-bin/demo.cgi/extra/path/info?abc=123
^^^^^^^^^^^^^^^^Das CGI demo.cgi wird mit PATH_INFO=/extra/path/info aufgerufen.
Oha, Wunder der Technik :)
und schon wieder was dazugelernt...
Urgs. Man lernt nie aus, danke! Das ist aber ein reichlich hinterhältiges Feature; bei relativen Adressen in so einer Seite bauen die Browser logischerweise Mist (was mich an der ganzen Sache dann auch gestört hat) - und wenn man nicht auf sowas vorbereitet ist.. ;]
In PHP hab ich eben einen kleinen Workaround für die nicht erwünschte PATH_INFO gestrickt:
if (isset($HTTP_SERVER_VARS["PATH_INFO"]))
{
$urlumleitung=$HTTP_SERVER_VARS["SCRIPT_NAME"] . "?" . $HTTP_SERVER_VARS["QUERY_STRING"];
header("Location: $urlumleitung");}
Ob das auch in SHTML machbar ist, weiß ich allerdings nicht.
Schönen Gruß aus Bilk
Rainer
P.S. Brauchst Du die Angaben aus meiner .htaccess noch?
-
http://www.example.com/cgi-bin/demo.cgi/extra/path/info?abc=123
^^^^^^^^^^^^^^^^Das CGI demo.cgi wird mit PATH_INFO=/extra/path/info aufgerufen.
Oha, Wunder der Technik :)
und schon wieder was dazugelernt...
Wohl war. Und kaum hat man die Funktionsweise verstanden, klärt sich auch, was hier bzw. bei meinem Hoster los ist. Ich hatte mich nämlich doch nicht geirrt: Dieser Quark trat bei meinem Hoster auch bei den eigentlich ganz stinknormalen HTML-Dateien auf; http://kino-fahrplan.de/programm/grindel.html/tralala hat er beispielsweise freundlichst auf den Tisch serviert.
Da mir ja nun endlich klar ist, woher das kommt, war der Grund dann auch schnell gefunden: eine Zeile "AddHandler server-parsed .html" in seiner httpd.conf..
Ich hab ja nix dagegen, wenn man sowas lokal in einem Verzeichnis macht, aber als serverweite Standardeinstellung - nee, wirklich :(In PHP hab ich eben einen kleinen Workaround für die nicht erwünschte PATH_INFO gestrickt:
if (isset($HTTP_SERVER_VARS["PATH_INFO"]))
{
$urlumleitung=$HTTP_SERVER_VARS["SCRIPT_NAME"] . "?" . $HTTP_SERVER_VARS["QUERY_STRING"];
header("Location: $urlumleitung");}
Ob das auch in SHTML machbar ist, weiß ich allerdings nicht.
Das if wäre kein Problem, aber SSI kann leider nicht weiterleiten oder sonst irgendwie einen echten Fehler erzeugen. Einziger allgemein brauchbarer Ansatzpunkt wäre wohl eine passende Rewrite-Regel, was mir aber auch nicht gerade elegant erscheint.
P.S. Brauchst Du die Angaben aus meiner .htaccess noch?
Nein, danke, "RemoveHandler .html" in meiner .htaccess tut's auch :)
Gruß und Danke nochmal an Euch,
soenk.e-
Hi Sönke,
Ob das auch in SHTML machbar ist, weiß ich allerdings nicht.
Das if wäre kein Problem, aber SSI kann leider nicht weiterleiten oder
sonst irgendwie einen echten Fehler erzeugen.Weiterleiten nicht - aber includen ... und darin Environment-Variablen
verwenden. Damit müßte man doch einen Zugriff auf einen modifizierten URL
hinkriegen, oder?Viele Grüße
MichaelP.S.: Nein, ich würde das natürlich _nicht_ so realisieren, sondern eher den
URL mit etwas umschreiben, was dafür gedacht ist (redirect, rewrite,
whatever).-
Ob das auch in SHTML machbar ist, weiß ich allerdings nicht.
Das if wäre kein Problem, aber SSI kann leider nicht weiterleiten oder
sonst irgendwie einen echten Fehler erzeugen.Weiterleiten nicht - aber includen ... und darin Environment-Variablen
verwenden. Damit müßte man doch einen Zugriff auf einen modifizierten URL
hinkriegen, oder?Einen Zugriff sicher, aber das Problem bleibt doch weiterhin bestehen: Der Client sieht einen erfolgreichen Abruf einer URL, obwohl diese nicht existiert bzw. existieren darf.
Solange man nicht den HTTP-Statuscode in Richtung 3xx oder besser noch 4xx ändert, kaschiert man vielleicht die Symptome, aber beseitigt nicht die Ursache.
So gesehen ist diese PATH_INFO-Angelegenheit zwar eine nette Sache, aber wenn man ungültige Zugriffe nicht direkt im Skript abfangen kann (wie es eben bei SSI der Fall ist), erscheint mir das nicht so recht durchdacht zu sein.. Da wäre eine Option DisallowPathInfo bei mod_include ganz hilfreich.
Gruß,
soenk.e-
So gesehen ist diese PATH_INFO-Angelegenheit zwar eine nette Sache, aber wenn man ungültige Zugriffe nicht direkt im Skript abfangen kann (wie es eben bei SSI der Fall ist), erscheint mir das nicht so recht durchdacht zu sein.. Da wäre eine Option DisallowPathInfo bei mod_include ganz hilfreich.
Das haben sich die Apache-Leute auch gedacht und prompt in ihre neue Version eingebaut.
http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo
-
-
-
-
Hallo,
In PHP hab ich eben einen kleinen Workaround für die nicht erwünschte PATH_INFO gestrickt:
if (isset($HTTP_SERVER_VARS["PATH_INFO"]))
{
$urlumleitung=$HTTP_SERVER_VARS["SCRIPT_NAME"] . "?" . $HTTP_SERVER_VARS["QUERY_STRING"];
header("Location: $urlumleitung");}
Da würde ich aber _unbedingt_ noch ein $HTTP_SERVER_VARS["HTTP_HOST"] mit einbauen, denn das ist laut HTTP/1.1-Spezifikation nicht gültig. (Location-Header müssen immer vollständige URIs enthalten; ich referenziere jetzt mal nicht auf das entspr. RFC, ich steh' damit nämlich auf Kriegsfuß [1])
Grüße,
Christian
[1] Ich wollte eine Funktion in PHP schreiben, die komplett laut Spezifikation das Accept-language:-Feld parsed. Am Ende hab' ich's doch hinbekommen, aber im RFC war's z.T so umständlich ausgedürckt, dass ich erst überlegt habe: was meint der Typ (die Typen) damit überhaupt?
-
-
-
-
-