mod_rewrite und Cookies (und div. Verständnisfragen)

[Gunther]

Hallo Forumsgemeinde!

Ich hätte da noch ein paar Fragen zu mod_rewrite. Selbst nach ausgiebigem Studium der entsprechenden Apache Dokumentationen und etlicher Tutorials dazu, habe ich immer noch gewisse Verständnisschwierigkeiten. Ich hoffe, ein paar davon mit eurer Hilfe beseitigen zu können.

Ich plane gerade für ein neues Projekt. Dabei sollen die Seiten dynmisch generiert werden, aber nach aussen hin durch kanonische (sprechende) URIs repräsentiert werden.

Zu diesem Zwecke verwende ich das mod_rewrite Modul des Apachen.

Folgendes habe ich bis jetzt zu Wege gebracht:
Das Projekt ist unter einer Subdomain beheimatet. Diese existiert wiederum unter zwei TLDs. Eine davon habe ich zur Hauptdomain gemacht.

http://sub.example.com/ => http://sub.example.de/
http://www.example.com/sub/ => http://sub.example.de/
http://www.example.de/sub/ => http://sub.example.de/

Diese RewriteRules habe ich direkt in die jeweiligen VirtualHost Abschnitte der conf gepackt.

Jetzt sollen alle Seitenaufrufe intern an die Datei index.php (im Root) weitergeleitet werden und die Adresse in der Browserzeile noch bei Bedarf "verschönert" werden. Dazu habe ich im Verzeichnis http://sub.example.de/ folgende .htaccess:
RewriteEngine on

do the rewrite

RewriteCond %{REQUEST_FILENAME} !-F
RewriteCond %{REQUEST_FILENAME} !^/var/www/web1/html/css/index.php$ [NC]
RewriteCond %{REQUEST_URI} ^(.*)(.|.htm|.html|.xhtml|.dhtml|.php|.php3|.php4|.php5)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)(.|/|.htm|.html|.xhtml|.dhtml|.php|.php3|.php4|.php5)$ http://%{HTTP_HOST}/$1 [R=301,QSA,L]

RewriteCond %{REQUEST_FILENAME} ^/var/www/web1/html/css/index$ [NC]
RewriteRule ^(.*)$ http://%{HTTP_HOST} [R=301,QSA,L]

RewriteCond %{REQUEST_FILENAME} ^/var/www/web1/html/css/index.php$ [NC]
RewriteCond %{QUERY_STRING} !^page=.*$
RewriteRule ^(.*)$ http://%{HTTP_HOST} [R=301,QSA,L]

RewriteCond %{REQUEST_FILENAME} !-F
RewriteCond %{REQUEST_FILENAME} !^/var/www/web1/html/css/index.php$ [NC]
RewriteRule ^(.*)$ index.php?page=$1 [QSA,L]

Das (zumindest scheint es so) funktioniert soweit auch wie beabsichtigt. Aus Performancegründen würde ich das Ganze ja auch lieber direkt in den VirtualHost Abschnitt packen, aber wenn ich das tue, funktioniert es nicht mehr wie gewünscht, sondern produziert einen 400 Bad Request.

Aber nun (endlich) zu meiner eigentlichen Frage:
Es gibt ja unter mod_rewrite etliche Flags mit denen sich u.a. auch Umgebungsvariablen und Cookies setzen lassen.

Um möglichst keine GET-Parameter an den URLs "kleben" zu haben, würde ich gerne Cookies verwenden. Nun ist ja (leider) das alte Thema das, dass man nicht davon ausgehen kann, dass jeder Client Cookies handeln kann, bzw. auch akzeptiert. Das einzige mir bekannte Prüfverfahren besteht also darin, dem Client ein Cookie zu senden und beim nächsten Request des Clients zu prüfen, ob das Cookie mitgesendet wurde.

Das Problem besteht also (hauptsächlich) darin, dass es immer eines neuen Requests bedarf.

Frage: Kann man das auch mit Hilfe von mod_rewrite irgendwie erreichen?

Ich könnte also bspw. irgendwo ein Cookie setzen mit
RewriteRule ^.*$ - [CO=acceptCookies:yes:sub.example.de:60:/]
(soweit so gut).
Nur wie kann ich jetzt den neuen Request erreichen? Denn ein Redirect [R] scheint das Problem nicht zu lösen, oder mache ich etwas falsch?

Überhaupt würde ich gerne noch ein paar Dinge für mein Verständnis nachfragen:

• Eins der größeren Probleme bereitet mir das Verstehen, wie oft und wann eigentlich überhaupt die einzelnen RewriteRules geprüft und angewendet werden. Ist es richtig, dass die RewriteRules abgearbeitet werden, bis daraus ein Redirect resultiert (dann geht es wieder von vorne los?), oder ein [L] Flag auftaucht?

• Was bewirken die Flags [NS] und [PT]? NS steht für 'Skip if internal subrequest'. Aber wann ist ein Request ein SUB-Request und wodurch entsteht er? PT steht für 'pass trough'. Wozu wird das gebraucht/ verwendet?

• Cookies und/ oder Umgebungsvariablen zu setzen bereitet mir keine Problem. Jedoch habe ich Schwierigkeiten, diese zu überprüfen. Wenn ich bspw. in einer Rule die folgende Umgebungsvariable setze: [E=CA:yes], dann sollte ich sie doch eigentlich per: RewriteCond %{ENV:CA} ^yes$ abfragen können? Analog bei den Cookies: RewriteCond %{HTTP_COOKIE} ^acceptCookies=yes$ ,bzw. RewriteCond %{CO:acceptCookies} ^yes$. Funktioniert aber nicht. Was mache ich falsch und/ oder wo liegt mein (Denk-)Fehler? Wie sieht es mit der Gültigkeit, bzw. der Lebensdauer von so gesetzten Variablen aus (nur bis zu einem Redirect oder auch darüber hinaus)?

Ich bin für jede Hilfe und jeden Tipp/ Hinweis dankbar. Ich komme alleine mit meinem Verstehen der Geschichte nicht mehr weiter.

Natürlich würde ich mich auch sehr freuen, wenn mir jemand eine performantere Version meiner bisherigen RewriteRules nennen könnte.

Also wie immer - meinen besten Dank im Voraus für jegliche Hilfe!

Gruß Gunther

PS: Bitte nicht als Doppelposting deklarieren. Ich weiss, dass ich hier bereits einen ähnlichen Thread habe. Aber das dort angesprochene Problem war ein anderes und der Umfang meiner neuen Fragen & Probleme rechtfertigt (hoffentlich) einen neuen Thread - Danke!

[wahsaga]

hi,

Das einzige mir bekannte Prüfverfahren besteht also darin, dem Client ein Cookie zu senden und beim nächsten Request des Clients zu prüfen, ob das Cookie mitgesendet wurde.

Damit weißt du, dass der Client also den Cookie mit diesem Request wieder mitgesendet hat.
Dass dies beim nächsten Request nicht mehr der Fall sein _muss_, sollte auf jeden Fall bewusst sein (auch wenn vielfach davon ausgegangen wird, macht PHP bei der Übertragung seiner Session-ID ja auch nicht anders).

Das Problem besteht also (hauptsächlich) darin, dass es immer eines neuen Requests bedarf.

Frage: Kann man das auch mit Hilfe von mod_rewrite irgendwie erreichen?

Ich könnte also bspw. irgendwo ein Cookie setzen mit
RewriteRule ^.*$ - [CO=acceptCookies:yes:sub.example.de:60:/]
(soweit so gut).
Nur wie kann ich jetzt den neuen Request erreichen? Denn ein Redirect [R] scheint das Problem nicht zu lösen, oder mache ich etwas falsch?

Wie hast du's denn gemacht?

(Ich bin mir nicht sicher, wie Clients auf einen Redirect reagieren, wenn dieser sie wieder zur selben Adresse schicken möchte.)

Und wenn das so geht, dann musst du natürlich auch abprüfen, ob beim nächsten Request der Cookie wieder mitgeschickt wurde - und dann nicht wieder erneut umleiten.

Überhaupt würde ich gerne noch ein paar Dinge für mein Verständnis nachfragen:

• Eins der größeren Probleme bereitet mir das Verstehen, wie oft und wann eigentlich überhaupt die einzelnen RewriteRules geprüft und angewendet werden. Ist es richtig, dass die RewriteRules abgearbeitet werden, bis daraus ein Redirect resultiert (dann geht es wieder von vorne los?), oder ein [L] Flag auftaucht?

Hast du den Abschnitt zum Ruleset Processing schon gelesen?

• Was bewirken die Flags [NS] und [PT]? NS steht für 'Skip if internal subrequest'. Aber wann ist ein Request ein SUB-Request und wodurch entsteht er?

Auch das sollte beim Durcharbeiten des Processing-Abschnittes deutlich werden.

PT steht für 'pass trough'. Wozu wird das gebraucht/ verwendet?

Um das Ergebnis des Rewritings an den nächsten Handler weiterzugeben.

"You must use this flag if you want to mix directives from different modules which allow URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite."

Das Kapitel Mapping URLs to Filesystem Locations könnte diesbezüglich auch noch ausschlussreich sein.

• Cookies und/ oder Umgebungsvariablen zu setzen bereitet mir keine Problem. Jedoch habe ich Schwierigkeiten, diese zu überprüfen. Wenn ich bspw. in einer Rule die folgende Umgebungsvariable setze: [E=CA:yes], dann sollte ich sie doch eigentlich per: RewriteCond %{ENV:CA} ^yes$ abfragen können? Analog bei den Cookies: RewriteCond %{HTTP_COOKIE} ^acceptCookies=yes$ ,bzw. RewriteCond %{CO:acceptCookies} ^yes$. Funktioniert aber nicht. Was mache ich falsch und/ oder wo liegt mein (Denk-)Fehler? Wie sieht es mit der Gültigkeit, bzw. der Lebensdauer von so gesetzten Variablen aus (nur bis zu einem Redirect oder auch darüber hinaus)?

M.E. müsste diese so lange andauern, bis der Apache den Request abgearbeitet hat.

"The variables can later be dereferenced in many situations, most commonly from within XSSI (via <!--#echo var="VAR"-->) or CGI ($ENV{'VAR'}). You can also dereference the variable in a later RewriteCond pattern, using %{ENV:VAR}."

Bei einem Redirect allerdings _ist_ er ja erst mal fertig, und übergibt die Steuerung wieder an den Client. Da ist die Umgebungsvariable also definitiv futsch.

gruß,
wahsaga

[Gunther]

Hallo wahsaga,

vielen Dank für deine Geduld & Ausdauer mit mir und meinem mod-rewrite Problem! :-)

Das einzige mir bekannte Prüfverfahren besteht also darin, dem Client ein Cookie zu senden und beim nächsten Request des Clients zu prüfen, ob das Cookie mitgesendet wurde.

Damit weißt du, dass der Client also den Cookie mit diesem Request wieder mitgesendet hat.
Dass dies beim nächsten Request nicht mehr der Fall sein _muss_, sollte auf jeden Fall bewusst sein (auch wenn vielfach davon ausgegangen wird, macht PHP bei der Übertragung seiner Session-ID ja auch nicht anders).

Hmm, das verstehe ich nicht ganz. Ich dachte gerade darin besteht der wesentliche Vorteil von Cookies, dass sie solange sie gültig (not expired) sind, immer mitgesendet werden (im Gegensatz zu GET-Parametern, die jedesmal manuell angehängt werden müssen)? Wie stelle ich denn sicher, dass das Cookie bei jedem Request mitgesendet wird?

Das Problem besteht also (hauptsächlich) darin, dass es immer eines neuen Requests bedarf.

Frage: Kann man das auch mit Hilfe von mod_rewrite irgendwie erreichen?

Ich könnte also bspw. irgendwo ein Cookie setzen mit
RewriteRule ^.*$ - [CO=acceptCookies:yes:sub.example.de:60:/]
(soweit so gut).
Nur wie kann ich jetzt den neuen Request erreichen? Denn ein Redirect [R] scheint das Problem nicht zu lösen, oder mache ich etwas falsch?

Wie hast du's denn gemacht?

Siehe meine .htaccess. Oben habe ich dann bspw. noch folgende Rule eingefügt:
RewriteRule ^.*$ - [CO=aCookies:5:sub.example.de:60:/]
(matched ja auf jeden Fall immer, verändert den Request nicht und setzt den/ das Cookie)

(Ich bin mir nicht sicher, wie Clients auf einen Redirect reagieren, wenn dieser sie wieder zur selben Adresse schicken möchte.)

Und wenn das so geht, dann musst du natürlich auch abprüfen, ob beim nächsten Request der Cookie wieder mitgeschickt wurde - und dann nicht wieder erneut umleiten.

Das Prüfen des Cookies ist ja u.a. eins meiner Probleme (siehe Ausgangsposting). Und umleiten muss ich eigentlich immer, da ein Request ja typischerweise so aussieht: http://sub.example.de/ein-artikel und intern weitergereicht wird an: http://sub.example.de/index.php?page=ein-artikel

Überhaupt würde ich gerne noch ein paar Dinge für mein Verständnis nachfragen:

• Eins der größeren Probleme bereitet mir das Verstehen, wie oft und wann eigentlich überhaupt die einzelnen RewriteRules geprüft und angewendet werden. Ist es richtig, dass die RewriteRules abgearbeitet werden, bis daraus ein Redirect resultiert (dann geht es wieder von vorne los?), oder ein [L] Flag auftaucht?

Hast du den Abschnitt zum Ruleset Processing schon gelesen?

Ja. Also ist es richtig, dass jeder Redirect ein neuer Request ist, bei dem alles wieder von vorne durchgegangen wird!?

• Was bewirken die Flags [NS] und [PT]? NS steht für 'Skip if internal subrequest'. Aber wann ist ein Request ein SUB-Request und wodurch entsteht er?

Auch das sollte beim Durcharbeiten des Processing-Abschnittes deutlich werden.

PT steht für 'pass trough'. Wozu wird das gebraucht/ verwendet?

Um das Ergebnis des Rewritings an den nächsten Handler weiterzugeben.

Ich habe (glaub ich zumindest) keine anderen Handler, die da noch etwas tun müssten. Bricht also dann das Ausführen einer RewriteRule mit dem [PT] Flag die Abarbeitung der übrigen RewriteRules ab!?

"You must use this flag if you want to mix directives from different modules which allow URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite."

OK, wie gesagt kommt mod_alias in dem betreffenden Fall nicht zum Einsatz.

Das Kapitel Mapping URLs to Filesystem Locations könnte diesbezüglich auch noch ausschlussreich sein.

• Cookies und/ oder Umgebungsvariablen zu setzen bereitet mir keine Problem. Jedoch habe ich Schwierigkeiten, diese zu überprüfen. Wenn ich bspw. in einer Rule die folgende Umgebungsvariable setze: [E=CA:yes], dann sollte ich sie doch eigentlich per: RewriteCond %{ENV:CA} ^yes$ abfragen können? Analog bei den Cookies: RewriteCond %{HTTP_COOKIE} ^acceptCookies=yes$ ,bzw. RewriteCond %{CO:acceptCookies} ^yes$. Funktioniert aber nicht. Was mache ich falsch und/ oder wo liegt mein (Denk-)Fehler? Wie sieht es mit der Gültigkeit, bzw. der Lebensdauer von so gesetzten Variablen aus (nur bis zu einem Redirect oder auch darüber hinaus)?

M.E. müsste diese so lange andauern, bis der Apache den Request abgearbeitet hat.

"The variables can later be dereferenced in many situations, most commonly from within XSSI (via <!--#echo var="VAR"-->) or CGI ($ENV{'VAR'}). You can also dereference the variable in a later RewriteCond pattern, using %{ENV:VAR}."

Also da ja alle meine Requests auf die index.php umgeleitet werden, ich teste das folgendermaßen:

  
print_r($_ENV);  

Da tauchen auch diverse Variablen auf, nur keine, die ich per mod_rewrite Flag gesetzt habe (bspw. per: [E=CA:yes]).

Bei einem Redirect allerdings _ist_ er ja erst mal fertig, und übergibt die Steuerung wieder an den Client. Da ist die Umgebungsvariable also definitiv futsch.

Ist denn aber nicht in die interne Umleitung auf meine index.php (im Normalfall) die letzte Umleitung und müsste nicht eine dort gesetzte Variable erhalten bleiben?

Noch eine neue Frage: Gibt es eigentlich eine Möglichkeit, einen evt. vorhandenen Querystring in der Adresszeile "abzuschneiden"_und_trotzdem intern (index.php) weiterzuverarbeiten? Bisher gehe ich davon aus, dass das nicht möglich ist. Denn eine Änderung in der Adresszeile kann ich doch nur durch einen Redirect erreichen. Und entweder schneide ich den Querystring dabei ab, oder ich hänge ihn per QSA-Flag wieder an. Richtig?

Gruß Gunther

[wahsaga]

hi,

Hmm, das verstehe ich nicht ganz. Ich dachte gerade darin besteht der wesentliche Vorteil von Cookies, dass sie solange sie gültig (not expired) sind, immer mitgesendet werden (im Gegensatz zu GET-Parametern, die jedesmal manuell angehängt werden müssen)?

Ja, wenn der Nutzer es seinem Browser erlaubt.

Wie stelle ich denn sicher, dass das Cookie bei jedem Request mitgesendet wird?

Als Nutzer: Stelle deinen Browser entsprechend ein, bzw. verbiete es ihm nicht.
Als Betreiber des Scriptes: Hoffe.

Und umleiten muss ich eigentlich immer, da ein Request ja typischerweise so aussieht: http://sub.example.de/ein-artikel und intern weitergereicht wird an: http://sub.example.de/index.php?page=ein-artikel

Dafür machst du doch aber keinen externen Redirect?
Sonst würde in der Adresszeile meines Browser ja dann
http://sub.example.de/index.php?page=ein-artikel
stehen.

Ja. Also ist es richtig, dass jeder Redirect ein neuer Request ist, bei dem alles wieder von vorne durchgegangen wird!?

Ja.

Wenn ich bspw. in einer Rule die folgende Umgebungsvariable setze: [E=CA:yes], dann sollte ich sie doch eigentlich per: RewriteCond %{ENV:CA} ^yes$ abfragen können?

Ja.

Analog bei den Cookies: RewriteCond %{HTTP_COOKIE} ^acceptCookies=yes$ ,bzw. RewriteCond %{CO:acceptCookies} ^yes$. Funktioniert aber nicht.

Der Cookie müsste ja erst mal zum Client gelangen, um von diesem beim _nächsten_ Request wieder mitgeliefert zu werden.

Also da ja alle meine Requests auf die index.php umgeleitet werden, ich teste das folgendermaßen:

print_r($_ENV);

> Da tauchen auch diverse Variablen auf, nur keine, die ich per mod\_rewrite Flag gesetzt habe (bspw. per: [E=CA:yes]).  
  
Safe Mode aktiviert?  
Dann [safe_mode_allowed_env_vars](http://www.php.net/manual/en/features.safe-mode.php#ini.safe-mode-allowed-env-vars) berücksichtigen.  
  

> Noch eine neue Frage: Gibt es eigentlich eine Möglichkeit, einen evt. vorhandenen Querystring in der Adresszeile "abzuschneiden"\_und\_trotzdem intern (index.php) weiterzuverarbeiten? Bisher gehe ich davon aus, dass das nicht möglich ist. Denn eine Änderung in der Adresszeile kann ich doch nur durch einen Redirect erreichen.  
  
Ja.  
  

> Und entweder schneide ich den Querystring dabei ab, oder ich hänge ihn per QSA-Flag wieder an. Richtig?  
  
Wenn du ihn abschneidest, sind die Daten damit verloren. Der Client schickt seinen nächsten Request ohne sie.  
  
gruß,  
wahsaga  
  

-- 
/voodoo.css:  
#GeorgeWBush { position:absolute; bottom:-6ft; }

[Gunther]

Hi,

Hmm, das verstehe ich nicht ganz. Ich dachte gerade darin besteht der wesentliche Vorteil von Cookies, dass sie solange sie gültig (not expired) sind, immer mitgesendet werden (im Gegensatz zu GET-Parametern, die jedesmal manuell angehängt werden müssen)?

Ja, wenn der Nutzer es seinem Browser erlaubt.

Wie stelle ich denn sicher, dass das Cookie bei jedem Request mitgesendet wird?

Als Nutzer: Stelle deinen Browser entsprechend ein, bzw. verbiete es ihm nicht.

achso..., ja da habe dich missverstanden.

Als Betreiber des Scriptes: Hoffe.

Ich will gerade herausfinden, ob der Client Cookies akzeptiert oder nicht. Aber so wie es aussieht, kommt man nicht drumherum, von einer Seite aus einen neuen Request zu erzeugen (z.B. mit header("Location: http://$host$uri");), um zu prüfen, ob ein  Cookie akzeptiert wurde oder nicht. Ich hatte die wage Hoffnung, dass es mit mod_rewrite auch anders ginge, aber du hast Recht - das Cookie muss ja erstmal zum Client kommen, bevor der es in einem neuen Request zurückschicken kann.

Und umleiten muss ich eigentlich immer, da ein Request ja typischerweise so aussieht: http://sub.example.de/ein-artikel und intern weitergereicht wird an: http://sub.example.de/index.php?page=ein-artikel

Ja. Also ist es richtig, dass jeder Redirect ein neuer Request ist, bei dem alles wieder von vorne durchgegangen wird!?

Ja.

Wenn ich bspw. in einer Rule die folgende Umgebungsvariable setze: [E=CA:yes], dann sollte ich sie doch eigentlich per: RewriteCond %{ENV:CA} ^yes$ abfragen können?

Ja.

Analog bei den Cookies: RewriteCond %{HTTP_COOKIE} ^acceptCookies=yes$ ,bzw. RewriteCond %{CO:acceptCookies} ^yes$. Funktioniert aber nicht.

Der Cookie müsste ja erst mal zum Client gelangen, um von diesem beim _nächsten_ Request wieder mitgeliefert zu werden.

Nein. Innerhalb der mod_rewrite Umgebung existiert der Cookie ja wie eine normale Variable sobald er einmal gesetzt ist. Also müsste er auch (schon) verfügbar sein. Und zwar unabhängig davon, ob er _später_ vom Client akzeptiert wird oder nicht.

Also da ja alle meine Requests auf die index.php umgeleitet werden, ich teste das folgendermaßen:

print_r($_ENV);

> > Da tauchen auch diverse Variablen auf, nur keine, die ich per mod\_rewrite Flag gesetzt habe (bspw. per: [E=CA:yes]).  
>   
> Safe Mode aktiviert?  
> Dann [safe_mode_allowed_env_vars](http://www.php.net/manual/en/features.safe-mode.php#ini.safe-mode-allowed-env-vars) berücksichtigen.  
  
Nein, kein safe\_mode!  
  

> > Noch eine neue Frage: Gibt es eigentlich eine Möglichkeit, einen evt. vorhandenen Querystring in der Adresszeile "abzuschneiden"\_und\_trotzdem intern (index.php) weiterzuverarbeiten? Bisher gehe ich davon aus, dass das nicht möglich ist. Denn eine Änderung in der Adresszeile kann ich doch nur durch einen Redirect erreichen.  
>   
> Ja.  
>   
> > Und entweder schneide ich den Querystring dabei ab, oder ich hänge ihn per QSA-Flag wieder an. Richtig?  
>   
> Wenn du ihn abschneidest, sind die Daten damit verloren. Der Client schickt seinen nächsten Request ohne sie.  
  
Hier kommen wieder die Umgebungsvariablen ins Spiel. Meine Idee war ja die, den Querystring in eine $\_ENV Variable zu packen. Somit könnte ich ihn in der Adresszeile "abschneiden" \_ohne\_ die Werte zu verlieren. Nur leider kommen die Variablen/ -werte ja gar nicht in meiner index.php an. :-(  
  
Das muss aber doch (eigentlich) vom Prinzip her funktionieren, oder?  
  
BTW: Ich habe ja durchaus vor, deinen Ratschlag bezüglich der Performance zu berücksichtigen, und die ganze Geschichte direkt in den VirtualHost Abschnitt zu packen. Aber irgendetwas läuft da anders, als wenn die Rules in der htaccess stehen. Wie müsste der ganze Klumpatsch denn für den VirtualHost Abschnitt aussehen? Ginge es auch mit weniger Conditions & Rules?  
  
Gruß Gunther

[wahsaga]

hi,

Ich will gerade herausfinden, ob der Client Cookies akzeptiert oder nicht. Aber so wie es aussieht, kommt man nicht drumherum, von einer Seite aus einen neuen Request zu erzeugen (z.B. mit header("Location: http://$host$uri");), um zu prüfen, ob ein  Cookie akzeptiert wurde oder nicht.

Nein, da hast du den Kern meiner Aussage nicht verstanden.
Wenn du ein mal überprüfst, ob du vom Client einen Cookie geschickt bekommst, muss das nicht heißen, dass das beim nächsten Request auch noch der Fall ist - der Benutzer kann es ja zwischendurch deaktivieren.
Zugegeben, das dürfte selten vorkommen - aber es _kann_ eben vorkommen.

Der Cookie müsste ja erst mal zum Client gelangen, um von diesem beim _nächsten_ Request wieder mitgeliefert zu werden.

Nein. Innerhalb der mod_rewrite Umgebung existiert der Cookie ja wie eine normale Variable sobald er einmal gesetzt ist.

Ist das eine Vermutung, oder irgendwo beschrieben?

Also müsste er auch (schon) verfügbar sein. Und zwar unabhängig davon, ob er _später_ vom Client akzeptiert wird oder nicht.

M.E. sagst du mod_rewrite, dass es in der Antwort auf den aktuellen Request einen Cookie-Header mitschicken soll.
Dass es deshalb so tut, als ob der Cookie schon mit dem aktuellen Request vom Client übermittelt worden wäre, bezweifle ich stark.

[Query-String] Wenn du ihn abschneidest, sind die Daten damit verloren. Der Client schickt seinen nächsten Request ohne sie.

Hier kommen wieder die Umgebungsvariablen ins Spiel. Meine Idee war ja die, den Querystring in eine $_ENV Variable zu packen. Somit könnte ich ihn in der Adresszeile "abschneiden" _ohne_ die Werte zu verlieren. Nur leider kommen die Variablen/ -werte ja gar nicht in meiner index.php an. :-(

Die Umgebungsvariablen existieren nur so lange, wie die Abarbeitung des aktuellen Requests andauert. Lässt du durch einen Redirect einen neuen Request aus, sind sie wieder futsch.
Und wenn du keinen Redirect auslöst, brauchst du die Daten nicht in eine weitere Umgebungsvariable zu stecken - dann reicht das Flag [QSA] vollkommen aus, um sie dem per interner Umschreibung aufgerufenen Script so zur Verfügung zu stellen, als wäre es direkt mit diesem Query-String aufgerufen worden.

BTW: Ich habe ja durchaus vor, deinen Ratschlag bezüglich der Performance zu berücksichtigen, und die ganze Geschichte direkt in den VirtualHost Abschnitt zu packen. Aber irgendetwas läuft da anders, als wenn die Rules in der htaccess stehen.

Was sagt das Rewrite Log dazu?

gruß,
wahsaga

[Gunther]

Hi,

Ich will gerade herausfinden, ob der Client Cookies akzeptiert oder nicht. Aber so wie es aussieht, kommt man nicht drumherum, von einer Seite aus einen neuen Request zu erzeugen (z.B. mit header("Location: http://$host$uri");), um zu prüfen, ob ein  Cookie akzeptiert wurde oder nicht.

Nein, da hast du den Kern meiner Aussage nicht verstanden.
Wenn du ein mal überprüfst, ob du vom Client einen Cookie geschickt bekommst, muss das nicht heißen, dass das beim nächsten Request auch noch der Fall ist - der Benutzer kann es ja zwischendurch deaktivieren.
Zugegeben, das dürfte selten vorkommen - aber es _kann_ eben vorkommen.

Prinzipiell ist das schon verstanden mit den Cookies ansich. Setzen wir jetzt mal voraus, dass der jeweilige Client für die Dauer der Sitzung die Cookies aktiviert lässt, sofern er das Cookie am Sitzungsbeginn akzeptiert hat.

Der Cookie müsste ja erst mal zum Client gelangen, um von diesem beim _nächsten_ Request wieder mitgeliefert zu werden.

Nein. Innerhalb der mod_rewrite Umgebung existiert der Cookie ja wie eine normale Variable sobald er einmal gesetzt ist.

Ist das eine Vermutung, oder irgendwo beschrieben?

Eine Vermutung, da ich bisher nirgendwo eine definitive Aussage dazu gefunden habe.

Also müsste er auch (schon) verfügbar sein. Und zwar unabhängig davon, ob er _später_ vom Client akzeptiert wird oder nicht.

M.E. sagst du mod_rewrite, dass es in der Antwort auf den aktuellen Request einen Cookie-Header mitschicken soll.
Dass es deshalb so tut, als ob der Cookie schon mit dem aktuellen Request vom Client übermittelt worden wäre, bezweifle ich stark.

Ich meine im Archiv bei meiner Suche mal über einen Artikel gestolpert zu sein, in dem Cheatah geschrieben hat, dass ein Redirect ja wieder zum Client gesendet wird und dieser somit dann einen neuen Request sendet. Was mir ja auch logisch erscheint, weil wie soll er sonst "mitkriegen", dass sich die Adresse (die er in der Adresszeile anzeigen soll) geändert hat?

Aber irgendwie kapiere ich das scheinbar nicht!?
Ich will ja eigentlich bloß wissen, ob ich per mod_rewrite feststellen kann, ob ein Client ein gesendetes Cookie akzeptiert hat oder nicht.

[Query-String] Wenn du ihn abschneidest, sind die Daten damit verloren. Der Client schickt seinen nächsten Request ohne sie.

Hier kommen wieder die Umgebungsvariablen ins Spiel. Meine Idee war ja die, den Querystring in eine $_ENV Variable zu packen. Somit könnte ich ihn in der Adresszeile "abschneiden" _ohne_ die Werte zu verlieren. Nur leider kommen die Variablen/ -werte ja gar nicht in meiner index.php an. :-(

Die Umgebungsvariablen existieren nur so lange, wie die Abarbeitung des aktuellen Requests andauert. Lässt du durch einen Redirect einen neuen Request aus, sind sie wieder futsch.
Und wenn du keinen Redirect auslöst, brauchst du die Daten nicht in eine weitere Umgebungsvariable zu stecken - dann reicht das Flag [QSA] vollkommen aus, um sie dem per interner Umschreibung aufgerufenen Script so zur Verfügung zu stellen, als wäre es direkt mit diesem Query-String aufgerufen worden.

Das kapier ich noch weniger, als die Sache mit den Cookies. In den diversen Dokumentationen ist immer die Rede davon, dass man die Umgebungsvariablen später (also nach Abarbeitung aller Requests durch u.a. mod_rewrite) bspw. in einem CGI-Script oder SSI Dateien nutzen kann.

Kriege ich eine Variable, die ich per Flag in einer RewriteRule setze auch in meine index.php weitergereicht oder geht das nicht?

BTW: Ich habe ja durchaus vor, deinen Ratschlag bezüglich der Performance zu berücksichtigen, und die ganze Geschichte direkt in den VirtualHost Abschnitt zu packen. Aber irgendetwas läuft da anders, als wenn die Rules in der htaccess stehen.

Was sagt das Rewrite Log dazu?

Das sagt, dass ja da vorher noch das sch... Confixx mit seinen ganzen Rewrites sitzt. Also werde ich es "bequemlichkeitshalber" erstmal weiter über die .htaccess machen (wobei ich die Sache mit der Performance durchaus verstanden habe), da ich auf das Confixx nicht (oder nur sehr schwer) verzichten kann (fehlende Linux- und Serveradministrationskenntnisse).

Gruß Gunther

[Gunther]

Hi,

Aber irgendwie kapiere ich das scheinbar nicht!?
Ich will ja eigentlich bloß wissen, ob ich per mod_rewrite feststellen kann, ob ein Client ein gesendetes Cookie akzeptiert hat oder nicht.

also mittlerweile bin ich mit meinem Verstehen der ganzen Geschichte etwas weiter vorangekommen.

Das Problem bei den Cookies ist, dass wenn jetzt ein Request vom Client ohne Cookie kommt, man nicht weiss, ob es daran liegt, dass dies der erste Request an diese Domain ist, oder daran, dass der Client keine Cookies akzeptiert.

Die einzige mir bekannte Möglichkeit dies zu prüfen, wäre die mittels des Referrers. Da dieser aber weder existent sein muss, noch zuverlässig ist, scheidet diese Methode also aus. Verbleibt also keine mehr.

Jetzt könnte man natürlich auch, wenn ein Request ohne Cookie reinkommt, hingehen und ein Cookie per mod_rewrite setzen. Um allerdings zu prüfen, ob der Client das Cookie akzeptiert hat, muss man nach dem Setzen des Cookies einen neuen Request erzeugen, also ein Redirect-Flag in der entsprechenden RewriteRule setzen. Soweit sogut. Das Problem besteht allerdings darin, dass man den neuen Request jedoch "wiedererkennen" muss, d.h. also von einem "normalen" Request ohne Cookie unterscheiden können muss, denn es könnte ja sein, dass eben im Falle der Ablehnung des Cookies durch den Client, kein Cookie mitgeschickt wird.

Hier taucht nun das Problem auf, dass man dazu entweder einen entsprechenden Querystring anhängen, oder die URL in irgendeiner Weise verändern muss, um diese "Erkennung" des Requests zu ermöglichen.

Will man jetzt aber keine unterschiedlichen URLs für mit und ohne Cookies haben, ist das Ganze wiederum zum Scheitern verurteilt, weil man ja nur_entweder_die URL intern umschreiben lassen kann,_oder_einen Redirect erzeugen kann (bei dem dann alle Umgebungsvariablen z.B. weg sind).

Oder kennt jemand eine Möglichkeit?

Die Umgebungsvariablen existieren nur so lange, wie die Abarbeitung des aktuellen Requests andauert. Löst du durch einen Redirect einen neuen Request aus, sind sie wieder futsch.

jo - eigentlich doof, wäre ansonsten nämlich u.a. für das obige Problem eine einfache und sichere Lösung.

Kriege ich eine Variable, die ich per Flag in einer RewriteRule setze auch in meine index.php weitergereicht oder geht das nicht?

So, jetzt hab' ich es herausgefunden!
Variablen, die man per E=VAR:VAL setzt, stehen anschließend in dem Array $_SERVER['REDIRECT_VAR'] (Groß-/ Kleinschreibung beachten! bei E=var:VAL ~ $_SERVER['REDIRECT_var'])!

Warum kann das keiner einfach so in sein Mod_Rewrite Tutorial schreiben!? Oder die Leute von der Apache-Doc!?

Aber da man die Variablen und ihre Werte ja leider nicht über einen Redirect rüberretten kann, braucht man das eigentlich eh nicht, da man dann genausogut gleich mit einem entsprechenden Querystring arbeiten kann.

Wenn aber jemand noch gute Ideen hat, insbesondere zu der Cookiegeschichte, würde ich mich über seine Antwort sehr freuen.

Bis dahin,
Gruß Gunther