Mein Debian Server hat so eine Art Autocomplete für die URIs.
hans
- webserver
Hallo
Wenn ich http://domain.com/request_uri eingebe, und gleichzeitig existiert das File request_uri.php im Webverzeichnis, dann wird die request_uri nichtmehr durch die .htaccess weiterverarbeitet, sondern gleich das File request_uri.php aufgerufen.
Hat jemand eine Ahnung wie ich diese dumme Funktion abstellen kann ?
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.6-1+lenny3
Wenn ich http://domain.com/request_uri eingebe, und gleichzeitig existiert das File request_uri.php im Webverzeichnis, dann wird die request_uri nichtmehr durch die .htaccess weiterverarbeitet, sondern gleich das File request_uri.php aufgerufen.
Hat jemand eine Ahnung wie ich diese dumme Funktion abstellen kann ?
Diese dumme Funktion fährt unter dem Namen Content Negotiation und wird meist benutzt, aus einer einer Reihe Übersetzungen automatisch die auszuliefern, die der Benutzer am ehesten versteht. So ziemlich jeder Browser übermittelt dazu die bevorzugten Sprachen, bekommt der Server eine Anfrage für ein Objekt, die er so nicht zuordnen kann (Datei seite.html existiert nicht), dann sucht er die nächstbesten mit Erweiterung (seite.html.de, seite.html.en, seite.html.it, etc).
Auf die gleiche Weise kann man Seiten vorab komprimieren (seite.html per gzip komprimieren und als seite.html.gz speicheren, daneben seite.html.html für Browser, die keine Komprimierung unterstützen; bei Aufruf seite.html liefert der Server jene der beiden Dateien, die der Browser anzeigen kann).
Wie du diese überaus nützliche dumme Funktion abschaltest, musst du in der Anleitung nachlesen. Da es "Debian-Server" nicht gibt und du offenbar .htaccess-Dateien verwendest, benutzt du wohl einen Apache-Server. Suche in der Server-Konfiguration nach "Multiviews". Abschalten in der .htaccess ist möglich, aber nicht so sinnig, wenn du Zugriff auf die Server-Konfiguration hast. Weiteres unter http://httpd.apache.org/docs/2.2/mod/core.html#options.
Moin!
Wenn ich http://domain.com/request_uri eingebe, und gleichzeitig existiert das File request_uri.php im Webverzeichnis, dann wird die request_uri nichtmehr durch die .htaccess weiterverarbeitet, sondern gleich das File request_uri.php aufgerufen.
Hat jemand eine Ahnung wie ich diese dumme Funktion abstellen kann ?
Diese dumme Funktion fährt unter dem Namen Content Negotiation
Nein. Es ist mod_speling.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Hi,
Wenn ich http://domain.com/request_uri eingebe, und gleichzeitig existiert das File request_uri.php im Webverzeichnis, dann wird die request_uri nichtmehr durch die .htaccess weiterverarbeitet, sondern gleich das File request_uri.php aufgerufen.
Hat jemand eine Ahnung wie ich diese dumme Funktion abstellen kann ?
Diese dumme Funktion fährt unter dem Namen Content Negotiation
Nein. Es ist mod_speling.
Nein, ist es nicht.
mod_speling korrigiert, neben abweichender Groß-/Kleinschreibung, „up to one misspelling (character insertion / omission / transposition or wrong character).”
/request_uri und /request_uri.php unterscheiden sich aber in mehr als einem Character.
Hingegen ist MultiViews genau für das beschriebene Verhalten verantwortlich - „If the server receives a request for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory looking for all files named foo.*”
MfG ChrisB
Moin!
Nein, ist es nicht.
Mod speling ergänzt nach meiner Erfahrung auch fehlende Dateiendungen. Endgültig können wir die Frage wohl nur klären wenn wir die komplette Serverkonfiguration sehen. Es kann nämlich auch ein Eintrag für den 404er sein.
Wenn man es ohne Blick in die Konfiguration wissen will:
1. request_uri.php anlegen. Inhalt: "php"
2. request_uri.htm anlegen. Inhalt: "htm"
http://.../request_uri aufrufen.
Kommt eine Rückfrage, was wohl gemeint sei, dann ist es mod_speling.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Endgültig können wir die Frage wohl nur klären wenn wir die komplette Serverkonfiguration sehen.
Ach, mit einem Male nicht mehr so bestimmt?
- request_uri.php anlegen. Inhalt: "php"
- request_uri.htm anlegen. Inhalt: "htm"
http://.../request_uri aufrufen.
Kommt eine Rückfrage, was wohl gemeint sei, dann ist es mod_speling.
Um es mit deinen Worten zu fassen: Nein, mod_negotiation. Das zeigt nämlich exakt das gleiche Verhalten.
Moin!
Kommt eine Rückfrage, was wohl gemeint sei, dann ist es mod_speling.
Um es mit deinen Worten zu fassen: Nein, mod_negotiation. Das zeigt nämlich exakt das gleiche Verhalten.
1. mod_negotiation fragt meines Wissens nicht.
2. Dann würde es mich sehr wundern, wenn er die php-Datei ausliefert.
Zitat:
"then the server reads the directory looking for all files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements, and returns that document."
PHP-Dateien haben von Haus aus einen Mime-Typ "application/x-php" - und den fordert der User-Agent bekanntlich eher selten an. Wie sollte mod_negotiation also dazu kommen einen PHP-Datei auszuliefern (oder deren Ausführung anzufordern? Der an den User-Agent zu sendende Mime-Typ (Content-Type) wird dann erst bei der Ausführung aus der php.ini gelesen oder im PHP-Skript mit header() gesetzt.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
ja, es war Multiviews. In der .htaccess die Zeile "Options -MultiViews" dazu, und passt jetzt.
Wie du diese überaus nützliche dumme Funktion abschaltest, musst du in der Anleitung nachlesen.
Sie wär nützlich wenn sie NACH der Abarbeitung der request_uri durch die .htaccess aktiv wäre (wo ich aus einfachen wörtern den endgültigen Link umrechne). Leider greift sie schon vorher ins Geschehen ein und lasst meine RewriteEngines nicht zum Schuss kommen.
Vielen Dank