Ist auch hier so | Problem mit Seitenaufruf. "domain/?kajsdvnf" wird auf Startseite geleitet | Alle Drupalseiten !!!
Eingetragen von drruebe (271)am 20.10.2012 - 11:03 Uhr in
Moin Moin,
ich habe da ein kleines Problem.
Im G.-Index sind jetzt wieder ein paar alte Domainkadaver von einem anderen CMS aufgetaucht ???
Wenn man da jetzt den Link anklickt domain/?cat=55 wird die Startseite angezeigt ebenso wenn man einfach nur domain/? eingibt.
Da es diese Seiten nicht gibt, frage ich mich wieso keine 404 Seite angezeigt wird.
Auch der Rex Swain http-Viewer zeigt diese aufrufe als reguläre Seite (200) an.
Selbst domain/?kjadsnvkjdfh landet auf der Startseite und das ist bei allen Installationen so.
Wie kann man das unterbinden?
Gruß Frank
Ich habe das auch gerade mal mit der Drupalcenter-Seite probiert. Hier wird das auch auf die Startseite geleitet. Das kann doch nicht sein, dass nur wegen dem /? Drupalseiten unter jeglichem Kaudawelsch zu erreichen sind.
drupal.org auch !!!
Das ist bei allen Drupalseiten so. Habe gerade ein Paar mit /?juiklsdfojredgn getestet.
Da muss ne Lösung her. HMM. Ich werd mal n bissel mit der htaccess rumprobieren, bisher war das nicht von Erfolg gekrönt.
Durch diesen Quatsch habe ich jetzt über 11000 Seiten im Index. Nur gut, dass es den cannoncial-Link gibt. Mir steht da gerade son bissel der Angstschweis auf der Stirn.
Hier mal die htaccess
#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$">
Order allow,deny
</FilesMatch>
# Don't show directory listings for URLs which map to a directory.
Options -Indexes
# Follow symbolic links in this directory.
Options +FollowSymLinks
# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php
# Set the default handler.
DirectoryIndex index.php index.html index.htm
# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_environment_initialize() in
# includes/bootstrap.inc for settings that can be changed at runtime.
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_flag magic_quotes_gpc off
php_flag magic_quotes_sybase off
php_flag register_globals off
php_flag session.auto_start off
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_flag mbstring.encoding_translation off
</IfModule>
# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
<FilesMatch \.php$>
# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off
</FilesMatch>
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Block access to "hidden" directories whose names begin with a period. This
# includes directories used by version control systems such as Subversion or
# Git to store control files. Files whose names begin with a period, as well
# as the control files used by CVS, are protected by the FilesMatch directive
# above.
#
# NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
# not possible to block access to entire directories from .htaccess, because
# <DirectoryMatch> is not allowed here.
#
# If you do not have mod_rewrite installed, you should remove these
# directories from your webroot or otherwise protect them from being
# downloaded.
RewriteRule "(^|/)\." - [F]
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# uncomment the following:
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment the following:
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
RewriteBase /
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
# Rules to correctly serve gzip compressed CSS and JS files.
# Requires both mod_rewrite and mod_headers to be enabled.
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
# Serve gzip compressed JS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
</IfModule>- Anmelden oder Registrieren um Kommentare zu schreiben
Nach dem Fragezeichen kommen
am 20.10.2012 - 13:43 Uhr
Nach dem Fragezeichen kommen Variablen, die die Seite auswerten kann. Also ist das ein absolut gültiger Aufruf für eine Seite und kann deshalb auch nicht auf einen 404-Error führen. Z.B. führt bei Drupal domain/?q=user auf die Login-Seite.
Beste Grüße
Werner
Hallo Werner, dass mit Login
am 20.10.2012 - 14:14 Uhr
Hallo Werner,
dass mit Login und so ist die eine Seite der Medaille, aber was ist mit den Variablen, die es faktisch nicht gibt und trotzdem auf die Startseite zeigen?
Das dürfte ja eigentlich nicht sein und wenn ich mich an meinen Anfang mit Drupal erinnere, so wurde ein Aufruf von z. Bsp. domai/?cat=88 (gibt es bei Drupal ja nicht) auf 404 gesetzt.
Ich war zur der Zeit heftigst am rumrödeln um einen htaccess-Hack für eine 301 zu basteln. Die Standartregeln funktionierten nämlich nicht. Und genau die jetzige Umleitung von Variablen auf die Startseite entspricht dieser Redirect-Anweisung ( domain/egal-was > zu Startseite > zu neue domain).
Das kann so nicht richtig sein, da ist irgendwo ein Fehler im Core, wenn nicht vorhandene Seiten und Variablen ohne Redirect (z. Bsp. unter Websiteeinstellungen 404) auf die Frontpage geleitet wird.
Gruß Frank
Das ist ein zulässiger
am 20.10.2012 - 16:46 Uhr
Das ist ein zulässiger Aufruf. Daher gibt es auch kein 404. Deine Startseite könnte z.B. ein JavaScript beinhalten, das genau diese Variable auswerten will. Damit wirst Du leben müssen.
Beste Grüße
Werner
drruebe schrieb Ist auch hier
am 21.10.2012 - 07:11 Uhr
Ist auch hier so | Problem mit Seitenaufruf. "domain/?kajsdvnf" wird auf Startseite geleitet | Alle Drupalseiten !!!
Das ist nicht nur bei Drupalseiten so, sondern bei allen anderen Webseiten auch. Probier es mal aus... Warum dies so ist, siehe Werners Beiträge.
Danke Anton, das war ein
am 21.10.2012 - 09:44 Uhr
Danke Anton, das war ein guter Hinweis und ich werde die Erklärung noch etwas deutlicher fassen:
Mit der Erweiterung der HTML-Spezifikation um Scriptsprachen wurde festgelegt, daß nach dem Fragezeichen Variablen folgen können. Diese Variablen können serverseitig, z.B. durch PHP, oder clientseitig, z.B. durch JavaScript, ausgewertet werden. Der Error 404 ist ein Server-Error. Den liefert z.B. Drupal zurück, wenn in der Variablen q kein gültiger Pfad vorkommt, also bei der Auswertung einer dem Server bekannten Variablen. Alle Variablen, die der Server nicht kennt, bleiben unberücksichtigt und lösen auch keinen Fehler aus, da dann erwartet wird, daß es sich um eine clientseitige Bearbeitung handeln wird.
Beste Grüße
Werner