Cookie via PHP geht nicht
Stefan 'Birdie' Vogel
ich versuche einen Cookie via PHP mit folgendem Code zu setzen:
<?php
// Inhalt festlegen
$inhalt = "Ich bin dein Cookie!";
// Cookie erzeugen
setcookie("cook_first_one",$inhalt, time()+600);
// Pr�fen
if (!$_COOKIE[cook_first_one]) {
echo "Cookie ist nicht vorhanden!";
} else {
echo $_COOKIE[cook_first_one];
}
?>
Irgendwie kommt aber immer "Cookie ist nicht vorhanden!" zur�ck, und es wird
anscheinend auch wirklich kein Cookie geschrieben.
Die Homepage liegt bei 1und1, falls das eine Rolle spielt, und generell
funktioniert PHP dort auch.
Mache ich was falsch, oder hat 1und1 da was gedreht, damit man eben keine
Cookies benutzen kann?
TSchau
--
____________________
(_____________
__________________) t e f a n
http://www.birdies.de - Die Seite um den iQ
http://www.iiih.de - Die Welt der K�fer
http://www.eggpeeling.com - Rund ums Ei
----
Michael Fesser
>ich versuche einen Cookie via PHP mit folgendem Code zu setzen:
>
><?php
>
>// Inhalt festlegen
>$inhalt = "Ich bin dein Cookie!";
>
>// Cookie erzeugen
>setcookie("cook_first_one",$inhalt, time()+600);
>
>// Pr�fen
>if (!$_COOKIE[cook_first_one]) {
> echo "Cookie ist nicht vorhanden!";
>} else {
> echo $_COOKIE[cook_first_one];
>}
>
>?>
>
>Irgendwie kommt aber immer "Cookie ist nicht vorhanden!" zur�ck, und es wird
>anscheinend auch wirklich kein Cookie geschrieben.
>Die Homepage liegt bei 1und1, falls das eine Rolle spielt, und generell
>funktioniert PHP dort auch.
Das Setzen und Auslesen eines Cookies innerhalb desselben Scripts
funktioniert prinzipbedingt nicht, Du brauchst in jedem Fall einen
zweiten Aufruf dieser Testseite im Browser.
Zudem solltest Du dringend Dein error_reporting hochdrehen. Wenn Du
keinen eigenen (lokalen) Testserver und somit keinen Zugriff auf die
php.ini hast, dann nutze die Funktion error_reporting() und setze den
Wert auf E_ALL|E_STRICT.
Micha
Claus Reibenstein
> if (!$_COOKIE[cook_first_one]) {
Sp�testens hier solltest Du eine Fehlermeldung erhalten, da es keine
Konstante cook_first_one gibt. Du meinst "cook_first_one" (mit
Anf�hrungszeichen).
Gru�. Claus
Stefan 'Birdie' Vogel
news:4v2gi5tsq9maboqt7...@4ax.com...
Hai,
ich habe jetzt:
======================
<?php
error_reporting(E_ALL);
// Inhalt festlegen
$inhalt = "Ich bin dein Cookie!";
// Cookie erzeugen
setcookie("cook_first_one",$inhalt, time()+600);
// Pr�fen
if (!$_COOKIE[cook_first_one]) {
echo "Cookie ist nicht vorhanden!";
} else {
echo $_COOKIE[cook_first_one];
}
echo "<br/>";
echo time()+600;
?>
=====================
Und bekomme dabei:
Warning: Cannot modify header information - headers already sent by (output
started at /homepages/....../test.php:1) in /homepages/......../test.php on
line 8
Notice: Use of undefined constant cook_first_one - assumed 'cook_first_one'
in /homepages/......../test.php on line 11
Notice: Undefined index: cook_first_one in /homepages/....../test.php on
line 11
Cookie ist nicht vorhanden!
1260918472
Ich frage mich nur, woher da noch eine Headerinfo kommt, das zwischen den
"=====" ist das komplette PHP-file, mehr steht da nicht drin, auch keine
leere Zeile oben oder so.
Tschau
Carsten Wiedmann
> ======================
> <?php
> ...
> setcookie("cook_first_one",$inhalt, time()+600);
>
> Und bekomme dabei:
> Warning: Cannot modify header information - headers already sent by
> (output started at /homepages/....../test.php:1) in
> /homepages/......../test.php on line 8
>
> den "=====" ist das komplette PHP-file, mehr steht da nicht drin, auch
> keine leere Zeile oben oder so.
Man könnt mal spekulieren, dass die Datei in UTF-8 mit BOM abgespeichert wurde?
Michael Fesser
>"Michael Fesser" <net...@gmx.de> schrieb im Newsbeitrag
>news:4v2gi5tsq9maboqt7...@4ax.com...
>>
>> Das Setzen und Auslesen eines Cookies innerhalb desselben Scripts
>> funktioniert prinzipbedingt nicht, Du brauchst in jedem Fall einen
>> zweiten Aufruf dieser Testseite im Browser.
>>
>> Zudem solltest Du dringend Dein error_reporting hochdrehen. Wenn Du
>> keinen eigenen (lokalen) Testserver und somit keinen Zugriff auf die
>> php.ini hast, dann nutze die Funktion error_reporting() und setze den
>> Wert auf E_ALL|E_STRICT.
>
>ich habe jetzt:
>======================
><?php
>error_reporting(E_ALL);
>// Inhalt festlegen
>
> $inhalt = "Ich bin dein Cookie!";
>
>// Cookie erzeugen
>setcookie("cook_first_one",$inhalt, time()+600);
>
>// Pr�fen
>if (!$_COOKIE[cook_first_one]) {
> echo "Cookie ist nicht vorhanden!";
>} else {
> echo $_COOKIE[cook_first_one];
>}
>echo "<br/>";
>echo time()+600;
>?>
>=====================
>Und bekomme dabei:
>Warning: Cannot modify header information - headers already sent by (output
>started at /homepages/....../test.php:1) in /homepages/......../test.php on
>line 8
Ich h�tte drauf wetten k�nnen, da� diese Meldung kommt.
>Notice: Use of undefined constant cook_first_one - assumed 'cook_first_one'
>in /homepages/......../test.php on line 11
>
>Notice: Undefined index: cook_first_one in /homepages/....../test.php on
>line 11
Diese beiden wurden bereits von Claus angesprochen und sollten gefixt
werden.
>Ich frage mich nur, woher da noch eine Headerinfo kommt, das zwischen den
>"=====" ist das komplette PHP-file, mehr steht da nicht drin, auch keine
>leere Zeile oben oder so.
Wenn das die einzige Datei ist und auch kein Leerraum au�erhalb der PHP-
Tags ist, dann bleibt als �blicher Verd�chtiger noch ein BOM (Byte Order
Mark). Das ist ein spezielles Zeichen am Anfang so mancher UTF-codierter
Dateien. PHP 5.x hat keine native Unicode-Unterst�tzung und daher auch
noch keine gesonderte Behandlung f�r solche BOMs.
Schau mal in Deinem Editor nach, in welcher Codierung die Datei
gespeichert wird und ob evtl. automatisch ein BOM eingef�gt wird.
Micha
Stefan Dreyer
Bzw. 'cook_first_ont', weil es geringf�gig performanter ist.
Stefan Froehlich
> >>if (!$_COOKIE[cook_first_one]) {
> > Du meinst "cook_first_one" (mit Anführungszeichen).
> Bzw. 'cook_first_ont', weil es geringfügig performanter ist.
Bzw. 'cook_first_one', weil es geringfuegig performanter ist, aber
gleichzeitig auch funktioniert.
SCNR,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Für Liebhaber: Stefan, die Lust zu haben!
(Sloganizer)
Claus Reibenstein
> Claus Reibenstein wrote:
>
>> Du meinst "cook_first_one" (mit Anf�hrungszeichen).
>
> Bzw. 'cook_first_ont', weil es geringf�gig performanter ist.
Abgesehen von Deinem Tippfehler ;-) hast Du nat�rlich Recht.
Gru�. Claus
Stefan Scholl
H�lt sich irgendwie hartn�ckig, das Ger�cht. :-(
http://www.phpbench.com/ (ganz unten, "Quote Types")
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Stefan Dreyer
> Stefan Dreyer <Stefan...@ddnetservice.net> wrote:
>> Claus Reibenstein wrote:
>>> Stefan 'Birdie' Vogel schrieb:
>>>
>>>> if (!$_COOKIE[cook_first_one]) {
>>> Sp�testens hier solltest Du eine Fehlermeldung erhalten, da es keine
>>> Konstante cook_first_one gibt. Du meinst "cook_first_one" (mit
>>> Anf�hrungszeichen).
>> Bzw. 'cook_first_ont', weil es geringf�gig performanter ist.
>
> H�lt sich irgendwie hartn�ckig, das Ger�cht. :-(
Weil es ja eigentlich auch logisch ist, aber wahrscheinlich nimmt sich
das nicht viel, da in ' auch nach dem Backslash gesucht werden muss.
> http://www.phpbench.com/ (ganz unten, "Quote Types")
Leider habe ich nichts zu verwendeten PHP-/Apache-Version gefunden. Ich
w�rde allerdings auch mal mehr als 1000 Durchl�ufen testen und nicht
unbedingt in einer Schleife, sondern als einzelne Aufrufe mit
unterschiedlichen Strings, damit dann Cachingeffekte ausgeschlossen
werden k�nnen. Die Zeiten im �s-Bereich halte ich so jedenfalls nicht
f�r repr�sentativ.
Vielleicht finde ich ja zu Weihnachten etwas Zeit, um das mal zu testen.
Stefan 'Birdie' Vogel
Yupp, der BOM war es... w�re ich so nie drauf gekommen, vielen Dank!
TSchau
Niels Braczek
>>> Bzw. 'cook_first_ont', weil es geringfügig performanter ist.
>>
>> Hält sich irgendwie hartnäckig, das Gerücht. :-(
>
> Weil es ja eigentlich auch logisch ist, aber wahrscheinlich nimmt sich
> das nicht viel, da in ' auch nach dem Backslash gesucht werden muss.
Suche mal in der Geschichte dieser Gruppe. Ich habe da vor geraumer Zeit
mal einen Benchmark gepostet. Da wird sich nicht viel verändert haben.
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Stefan Dreyer
> Stefan Dreyer schrieb:
>
>>Stefan Scholl wrote:
>>
>>>Stefan Dreyer <Stefan...@ddnetservice.net> wrote:
>
>
>>>>Bzw. 'cook_first_ont', weil es geringfügig performanter ist.
>>>
>>>Hält sich irgendwie hartnäckig, das Gerücht. :-(
>>
>>Weil es ja eigentlich auch logisch ist, aber wahrscheinlich nimmt sich
>>das nicht viel, da in ' auch nach dem Backslash gesucht werden muss.
>
>
> Suche mal in der Geschichte dieser Gruppe. Ich habe da vor geraumer Zeit
> mal einen Benchmark gepostet. Da wird sich nicht viel verändert haben.
Hast Du noch nähere Informationen? Das, was mir der Suchknecht geliefert
hat, bezog sich nicht auf "" vs. ''.
Niels Braczek
> Niels Braczek wrote:
>> Suche mal in der Geschichte dieser Gruppe. Ich habe da vor geraumer Zeit
>> mal einen Benchmark gepostet. Da wird sich nicht viel verändert haben.
>
> Hast Du noch nähere Informationen? Das, was mir der Suchknecht geliefert
> hat, bezog sich nicht auf "" vs. ''.
Ich finde den auch nicht mehr... der Vergleich bezog sich auf die
verschiedenen Möglichkeiten, mehrere Strings mit echo auszugeben; der
Vergleich "" vs. '' war nur ein Teilproblem. Das Ergebnis war, dass
einfache Anführungszeichen bei konstanten Strings geringfügig schneller
sind.
In diese Richtung zu optimieren ist allerdings gelinde gesagt
fragwürdig. Lesbarkeit hat absoluten Vorrang vor der Einsparung von ein
oder zwei Millisekunden. Und da zählt die eigene Vorliebe bzw. - falls
vorhanden - der StyleGuide. Performance gewinnt man jedenfalls an
anderen Stellen.
Stefan Dreyer
> Stefan Dreyer schrieb:
>
>>Niels Braczek wrote:
>
>
>>>Suche mal in der Geschichte dieser Gruppe. Ich habe da vor geraumer Zeit
>>>mal einen Benchmark gepostet. Da wird sich nicht viel verändert haben.
>>
>>Hast Du noch nähere Informationen? Das, was mir der Suchknecht geliefert
>>hat, bezog sich nicht auf "" vs. ''.
>
>
> Ich finde den auch nicht mehr... der Vergleich bezog sich auf die
> verschiedenen Möglichkeiten, mehrere Strings mit echo auszugeben; der
> Vergleich "" vs. '' war nur ein Teilproblem. Das Ergebnis war, dass
> einfache Anführungszeichen bei konstanten Strings geringfügig schneller
> sind.
Das ist ja nun zumindest das erwartete Ergebnis.
> In diese Richtung zu optimieren ist allerdings gelinde gesagt
> fragwürdig.
Das auf jeden Fall.
> Lesbarkeit hat absoluten Vorrang vor der Einsparung von ein
> oder zwei Millisekunden. Und da zählt die eigene Vorliebe bzw. - falls
> vorhanden - der StyleGuide.
Bei mir: Strings mit HTML-Inhalt in '', damit man nicht so viel "
escapen muss. Bei SQL-Strings umgekehrt.
> Performance gewinnt man jedenfalls an
> anderen Stellen.
Ohja, das ist eine Optimierung, die nur dann etwas bringt, wenn
Schleifen entsprechend häufig durchlaufen werden. Lustig finde ich, dass
der Extension Kickstarter von Typo3 extra eine Option bietet, die "" zu
'' Konvertierung vorzunehmen.
Die meisten Performanceprobleme lassen sich durch ein vernünftiges
DB-Design und durch Programmoptimierung beseitigen.
Niels Braczek
> Niels Braczek wrote:
>> Lesbarkeit hat absoluten Vorrang vor der Einsparung von ein
>> oder zwei Millisekunden. Und da zählt die eigene Vorliebe bzw. - falls
>> vorhanden - der StyleGuide.
>
> Bei mir: Strings mit HTML-Inhalt in '', damit man nicht so viel "
> escapen muss. Bei SQL-Strings umgekehrt.
Das halte ich auch so.
Zusätzlich sind bei mir Strings, deren Wert für die Applikation
entscheidend sind (zB. Indizes von assoziativen Arrays), in einfachen,
die anderen (zB. Mitteilungen an den Benutzer) in doppelten
Anführungszeichen (ich lasse die beiden Stringvarianten unterschiedlich
highlighten).
>> Performance gewinnt man jedenfalls an
>> anderen Stellen.
> Ohja, das ist eine Optimierung, die nur dann etwas bringt, wenn
> Schleifen entsprechend häufig durchlaufen werden.
Auch dann nicht. Um einen signifikanten Unterschied zu erzielen, müssen
das schon 100.000 Strings oder mehr sein - gegen die Übertragungszeit
ist der Performanz-Unterschied lächerlich.
> Lustig finde ich, dass
> der Extension Kickstarter von Typo3 extra eine Option bietet, die "" zu
> '' Konvertierung vorzunehmen.
Naja, Typo3 macht ja alles anders als andere...
> Die meisten Performanceprobleme lassen sich durch ein vernünftiges
> DB-Design und durch Programmoptimierung beseitigen.
*Alle* Performanceprobleme lassen sich erst nach ihrer Identifizierung
durch ein Profiling beheben.
Michael Fesser
>Niels Braczek wrote:
>
>> Lesbarkeit hat absoluten Vorrang vor der Einsparung von ein
>> oder zwei Millisekunden. Und da z�hlt die eigene Vorliebe bzw. - falls
>> vorhanden - der StyleGuide.
>
>Bei mir: Strings mit HTML-Inhalt in '', damit man nicht so viel "
>escapen muss. Bei SQL-Strings umgekehrt.
Escapen brauchst Du h�chstens bei eingebettetem JavaScript, aber nicht
bei reinem HTML - da sind seit jeher auch einfache Anf�hrungszeichen
zul�ssig. Bei mir gibt's �fter solche Konstruktionen:
print "<someTag someAttr='$value'>...</someTag>\n";
>> Performance gewinnt man jedenfalls an
>> anderen Stellen.
>
>Ohja, das ist eine Optimierung, die nur dann etwas bringt, wenn
>Schleifen entsprechend h�ufig durchlaufen werden.
Nur w�ren das dann schon Gr��enordnungen, die real praktisch nicht
erreicht werden.
Micha
![Ulf [Kado] Kadner's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWS0V3TJwJ-07-NWcLG9HZ4SMFbgzyAMxottO1QqD5V2n_1h37R=s40-c)
Ulf [Kado] Kadner
> Stefan Dreyer schrieb:
>> Bei mir: Strings mit HTML-Inhalt in '', damit man nicht so viel "
>> escapen muss. Bei SQL-Strings umgekehrt.
>
> Das halte ich auch so.
Ich nutze in PHP generell nur dann Doublequtes wenn diese
Maskierungssequenzen wie \t \r \n \0x20 etc. enthalten. Da ich SQL
generell in XML-Dateien ablege besteht hier kein Bedarf meinerseits für
mehr Anwendungsbereiche von ".
Aber eins will ich nochmal anmerken:
Diese Geschichte «'' vs. ""» stammt nicht von Ungefähr! Will heissen das
diese Debatte vor längerer Zeit durchaus Ihre Berechtigung hatte.
Ich hab hier noch ne alte 4.0.3 Php-Version mit der hab ich mal die
üblichen Vergleiche der Ausführungszeiten gemacht. Damals waren die
Unterschiede '' zu "" wesentlich deutlicher und durchaus erwähnenswert.
Aber die Entwicklung der Innereien von PHP ist halt auch nicht stehen
geblieben und mit halbwegs aktuellen PHP-Versionen kann man wirklich
nicht mehr sagen das eins von beiden zu bevorzugen wär.
MfG, Ulf
--
Die Eintagsfliege wird bereits zwölf Stunden nach ihrer Geburt von
ihrer Midlife - Crisis erwischt. Das muß man sich mal klarmachen!
[Loriot]
Stefan Scholl
Also kommt es nicht so sehr auf Geschwindigkeit an. :-)
Ulf [Kado] Kadner
> Ulf [Kado] Kadner <dr_l...@gmx.net> wrote:
>> Da ich SQL
>> generell in XML-Dateien ablege besteht hier kein Bedarf meinerseits
>> für
>
> Also kommt es nicht so sehr auf Geschwindigkeit an. :-)
In gewisser Weise hast Du damit zwar recht, aber das kommt erst dann zum
tragen wenn es überhaupt zu Performanceproblemen kommt.
Selbst auf schwachbrüstigen Kundenwebspace oder billigen V-Servern
spielen die paar IO-Zugriffe keine nennenswerte Rolle. SimpleXML ist
schnell genug um hier Staus zu vermeiden.
Btw. XML-Daten im Vergleich zu direkt in PHP definierten Zeichenketten.
Ich hab mal als ich für meine Webseite http://projekte.softsteps.de die
Testcases geschrieben habe auch ein par Performancetests gebaut.
Das einlesen aller im XML definierten SQL-Queries (12 Tabellen also 12
XML-Dateien mit insgesamt 167 Queries) dauert durchschnittlich 332µs
länger wie normale Queriedefinition in PHP-Code und einbindung mit
require oder include
Ich glaub da kommt kein besucher auch die Idee sich deswegen zu
beschweren. Außerdem läuft auf meinem Webserver noch Zend-Optimizer,
dessen erzielter Performancegewinn in der Messung noch garnicht zum
Tragen kommt.
MfG, Ulf
--
Ein Dutzend verlogener Komplimente ist leichter zu ertragen als ein
einziger aufrichtiger Tadel. [Mark Twain]