nicht angemeldet
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