it-swarm.com.de

RewriteRule funktioniert nicht für eine CSS-Datei und ein Dokument, wenn eine RewriteCondition hinzugefügt wird, um zu testen, ob sich ein Name-Wert-Parameter in der Abfragezeichenfolge befindet

Ich versuche, den DocumentRoot über .htaccess in subfolder zu ändern.

Das funktioniert gut ...

RewriteCond %{REQUEST_URI} !subfolder/
RewriteRule ^(.*)$ /subfolder/$1

Ich möchte dies jedoch nur tun, wenn ein bestimmter Abfrageparameter (var=test) festgelegt ist.

RewriteCond %{QUERY_STRING} ^var=test$
RewriteCond %{REQUEST_URI} !subfolder/
RewriteRule ^(.*)$ /subfolder/$1

... aber aus irgendeinem Grund funktioniert das nicht.

Irgendwelche Vorschläge, was das Problem sein könnte?


PDATE: Hier ist ein vollständiges (vereinfachtes) Beispiel:

htaccess

RewriteEngine on
RewriteCond %{QUERY_STRING} (.*(?:^|&))var=test((?:&|$).*)
RewriteCond %{REQUEST_URI} !sites/test/
RewriteRule ^(.*)$ /sites/test/$1

sites/test/index.php

<!DOCTYPE html>
<html>
<head>
    <title>Test</title>
    <link rel="stylesheet" type="text/css" href="styles.css">
</head>
<body>
    <p>Test</p>
</body>
</html>

sites/test/styles.css

* {
    color: red;
}

Versuchen Sie nun, die Seite mit http://example.com/?var=test zu laden. Der Text Test sollte rot sein, ist es aber nicht.

Entfernen Sie die QUERY_STRING RewriteCond -Zeile, und es funktioniert.

Aber ich muss irgendwie in der Lage sein, nach der Abfragezeichenfolge zu suchen.

Apache Virtual Host (falls erforderlich)

<VirtualHost *:80>

      ServerName www.example.com
      ServerAdmin [email protected]

      DocumentRoot "/var/www/mainsite"
      <Directory />
              Options FollowSymLinks
              AllowOverride None
      </Directory>
      <Directory "/var/www/mainsite">
              Options Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              allow from all
      </Directory>

</VirtualHost>
4
camursm

Aus irgendeinem Grund bricht der zweite Codeblock oben die CSS-Dateipfade und ich kann nicht herausfinden, warum ...

Der einzige Unterschied zum zweiten Codeblock besteht darin, dass die Anforderung für Ihre CSS-Datei (en) nicht neu geschrieben wird. Während es für den ersten Codeblock sein wird. Ihre CSS-URL enthält nicht den URL-Parameter var=test. Es wird nur die URL der Hauptseite neu geschrieben, die den URL-Parameter enthält.

Wenn also eine Anfrage für http://example.com/?var=test vorliegt, wird /styles.css anstelle von /sites/test/styles.css angefordert (und nicht umgeschrieben), was die Absicht zu sein scheint.


PDATE # 1: Wie in den Kommentaren erwähnt, wäre es wahrscheinlich nicht praktisch, dies mit .htaccess zu lösen. Die Anforderung für die CSS-Datei ist eine völlig separate Anforderung. Es gibt hier kein Konzept einer "Sitzung" (oder vielmehr einer "Seitenanforderung"). Sie müssten auf Cookies zurückgreifen, um den Status beizubehalten - was die Komplexität erhöht (für andere Anforderungen nicht festgelegt werden muss) und möglicherweise nicht zuverlässig ist. Wenn Sie bei der Abfragezeichenfolge bleiben möchten , können Sie dies in PHP lösen, indem Sie nach var=test suchen. Abfragezeichenfolge und manuelles Anhängen dieser an die CSS-URL in Ihrem HTML. (Oder sogar den richtigen (vollständigen) URL-Pfad an die CSS-URL in Ihrem HTML-Code anhängen - obwohl Sie vielleicht versuchen, den tatsächlichen URL-Pfad vor Ihren Benutzern zu verbergen, so dass dies möglicherweise nicht wünschenswert ist.)

Zum Beispiel:

<?php
$resourceQueryString = '';
if (isset($_GET['var']) && ($_GET['var'] == 'test')) {
    $resourceQueryString = '?var=test';
}
?>
<!DOCTYPE html>
<html>
<head>
    <title>Test</title>
    <link rel="stylesheet" type="text/css" href="styles.css<?=$resourceQueryString?>">
</head>
<body>
    <p>Test</p>
</body>
</html>

Dies prüft natürlich auf var=test irgendwo in der Abfragezeichenfolge, nicht wörtlich nur auf ?var=test.

Wenn Sie jedoch über 100 statische Seiten verfügen, ist dies möglicherweise auch nicht praktikabel.


PDATE # 2: Wenn Sie den "Cookie" -Ansatz in .htaccess ausprobieren wollten, könnten Sie möglicherweise Folgendes tun (ungetestet):

RewriteEngine on

# If query string passed then set a (session) cookie...
RewriteCond %{QUERY_STRING} (?:^|&)var=test(?:&|$)
RewriteRule ^ - [CO=rewrite_trigger:1:.example.com]

# If no query string and a ".php" request then unset cookie
RewriteCond %{QUERY_STRING} !var=test
RewriteRule \.php$ - [CO=rewrite_trigger:0:.example.com:-1]

# Rewrite request if query string OR cookie is set
RewriteCond %{QUERY_STRING} (?:^|&)var=test(?:&|$) [OR]
RewriteCond %{HTTP_COOKIE} rewrite_trigger=1
RewriteCond %{REQUEST_URI} !^/sites/test/
RewriteRule (.*) /sites/test/$1 [L]

Ändern Sie .example.com entsprechend Ihrer Domain.

Bedenken Sie, dass der Cookie bei der Anforderung, bei der der Cookie gesetzt wird, nicht lesbar ist. Das Cookie kann nur bei nachfolgenden Anforderungen gelesen werden, daher muss entweder die Abfragezeichenfolge OR des Cookies überprüft werden.

Beachten Sie, dass dies derzeit nicht getestet ist (kann später getestet werden, wenn ich Zeit habe). Wenn Sie darüber nachdenken, liegt möglicherweise ein Problem mit der ersten .php -Anforderung ohne die Abfragezeichenfolge nach einem .php vor. fordern Sie mit der Abfragezeichenfolge an (da das Cookie weiterhin gesetzt wird). Benötigen Sie möglicherweise eine Umgebungsvariable , um dies zu beheben? Oder vielleicht nach (Abfragezeichenfolge AND .php) OR (Cookie AND no .php) suchen, um es neu zu schreiben?

4
MrWhite