Hi All, habe das Problem, dass mit SUSE9.2 keine Cookies mehr gesendet werden. Mit 9.0 lief die gleiche Software ( phpOpenTracker ) einwandfrei. Kennt jemand das Thema? Oder kann mir sagen wo ich troubleshooten könnte? apache config ? php.ini ? Grüsse, Dirk
Hallo Dirk, hallo Leute, Am Montag, 24. Januar 2005 16:40 schrieb Dirk Eberhardt (deberhar):
habe das Problem, dass mit SUSE9.2 keine Cookies mehr gesendet werden.
Mit 9.0 lief die gleiche Software ( phpOpenTracker ) einwandfrei.
Kennt jemand das Thema? Oder kann mir sagen wo ich troubleshooten könnte? apache config ? php.ini ?
Anhand Deiner Fehlerbeschreibung ist das schwer zu sagen. Deshalb mal ein paar Anhaltspunkte: - bist Du sicher, dass die Cookies nicht gesendet werden? (Sprich: Wie hast Du das festgestellt/getestet?) (es könnte genausogut sein, dass die Cookies nicht vom Browser zum Server zurückgeschickt werden.) - hast Du die Annahme von Cookies im Browser verboten? - hast Du an der php.ini irgendwas verändert? - irgendwelche PHP-Fehlermeldungen? - falsche Expire-Time der Cookies? - Welche Art Cookies? Ein Session-Cookie oder ein "normales"? Im Zweifelsfall teste mal den Abruf der Seite, die das Cookie setzt, per telnet servername 80 GET /pfad/zu/datei.html HTTP/1.0 Host: www.servername.de <zweimal Return> Interessant sind die ersten ausgegebenen Zeilen, bevor der HTML-Quelltext anfängt. Diese sehen beispielsweise so aus: | HTTP/1.1 200 OK | Date: Fri, 28 Jan 2005 21:03:28 GMT | Server: Apache/2.0.50 (Linux/SUSE) | X-Powered-By: PHP/4.3.8 | Connection: close | Content-Type: text/html; charset=ISO-8859-1 Falls eine Seite ein Cookie setzen will, müsste das ebenfalls in diesem Bereich mit ausgegeben werden: | Set-Cookie: PHPSESSID=3494200fa1058d5fb2f843bd5f8a66a5; path=/ Gruß Christian Boltz -- Linux: und wo bitte ist mein blauer Bildschirm ?
Hallo, Am Fri, 28 Jan 2005, Christian Boltz schrieb: [..]
Im Zweifelsfall teste mal den Abruf der Seite, die das Cookie setzt, per telnet servername 80 GET /pfad/zu/datei.html HTTP/1.0
Du kennst 'GET' und 'HEAD' bzw. 'lwp-request' dem LWP-Paket von perl? $ HEAD http://servername/pfad/zu/Datei.html Ueber Optionen (von GET) kann man auch Header und Dokument anzeigen. -dnh -- Ach Du armes kleines... Du fuehst Dich einsam, alleingelassen? Du glaubst, alle wuerden Dich misverstehen? Aber nein, hier in dag° koennen wir gut nachfuehlen, wie es Dir geht. Ach du meine Guete, wenn man mich immer "cdipop" rufen wuerde, tagtaeglich, ich wuerde ausrasten! [Axel Woelke zu 'cdipop25 in dag°]
Hallo David, hallo Leute, Am Samstag, 29. Januar 2005 03:21 schrieb David Haller:
Am Fri, 28 Jan 2005, Christian Boltz schrieb: [..]
Im Zweifelsfall teste mal den Abruf der Seite, die das Cookie setzt, per telnet servername 80 GET /pfad/zu/datei.html HTTP/1.0
Du kennst 'GET' und 'HEAD' bzw. 'lwp-request' dem LWP-Paket von perl?
Ja, aber...
... # GET "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported Irgendwie hat GET Probleme mit meinem wwwoffle, der in $HTTP_PROXY angegeben ist. (Dass lj.tux ein interner Name ist, brauche ich wohl nicht zu erwähnen.) Bei HEAD ergibt sich ein ähnliches Bild: # HEAD "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported Content-Type: text/plain Client-Date: Sat, 29 Jan 2005 22:11:22 GMT Client-Warning: Internal response Mit telnet servername 80 funktioniert das Ganze, sodass ich zum Testen eben das verwende. HTTP_PROXY="" GET ... funktioniert übrigens auch, aber inzwischen habe ich mich an telnet auf Port 80 gewöhnt ;-) Gruß Christian Boltz PS: Um die Freenet-Zwangsumleitung zu umgehen, steht übrigens ein HEAD-Aufruf in meiner ip-up.local ;-) -- Das einzige Feature von OE das du unter Linux nicht nachgebaut bekommen wirst: Die Virenschleuder ;-) [Damian Philipp in suse-linux]
Hallo, Am Sat, 29 Jan 2005, Christian Boltz schrieb:
Am Samstag, 29. Januar 2005 03:21 schrieb David Haller:
Am Fri, 28 Jan 2005, Christian Boltz schrieb: [..]
Im Zweifelsfall teste mal den Abruf der Seite, die das Cookie setzt, per telnet servername 80 GET /pfad/zu/datei.html HTTP/1.0
Du kennst 'GET' und 'HEAD' bzw. 'lwp-request' dem LWP-Paket von perl?
Ja, aber...
... # GET "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported
Irgendwie hat GET Probleme mit meinem wwwoffle, der in $HTTP_PROXY angegeben ist.
1. heisst die Variable (z.B. fuer lynx, w3m und links) http_proxy und 2. kennt lwp-request (also GET, HEAD) die Option -p. -dnh -- The damn daystar is up, feeding me non-CRT radiation. I hear RFC1149 conduits feeping outside my window. -- Steed in asr
Hallo David, hallo Leute, Am Samstag, 29. Januar 2005 23:33 schrieb David Haller:
Am Sat, 29 Jan 2005, Christian Boltz schrieb:
Am Samstag, 29. Januar 2005 03:21 schrieb David Haller:
Du kennst 'GET' und 'HEAD' bzw. 'lwp-request' dem LWP-Paket von perl?
... # GET "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported
Irgendwie hat GET Probleme mit meinem wwwoffle, der in $HTTP_PROXY angegeben ist.
1. heisst die Variable (z.B. fuer lynx, w3m und links) http_proxy und
GET verwendet wirklich $HTTP_PROXY, siehe nebenan. Ich weiß nicht warum, aber es ist so ;-)
2. kennt lwp-request (also GET, HEAD) die Option -p.
Klar, aber wenn schon Handarbeit, dann lieber telnet auf Port 80 *g* Gruß Christian Boltz -- Spätestens dabei handelt es sich um Filtereffekte, die ImageMagick bestimmt nicht beherrschen kann. Sollten sie _das_ nachprogrammiert haben, würde ich barfuß hinlaufen und ihnen ein halbes Schwein opfern ob ihrer Genialität. [Ratti in suse-linux]
On Sat, Jan 29, 2005 at 11:17:36PM +0100, Christian Boltz wrote:
Ja, aber... ... # GET "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported
Klingt ganz stark danach, das deine http_proxy Variable nicht richtig gesetzt ist. Du hast bestimmt nur "localhost:3128" oder aenliches eingefuellt, aber in die Variable muss "http://localhost:3128/" gesetzt werden. -- Peter
Hallo Peter, hallo Leute, Am Sonntag, 30. Januar 2005 14:21 schrieb Peter Wiersig:
On Sat, Jan 29, 2005 at 11:17:36PM +0100, Christian Boltz wrote:
Ja, aber... ... # GET "http://lj.tux/" 501 Protocol scheme 'localhost' is not supported
Klingt ganz stark danach, das deine http_proxy Variable nicht richtig gesetzt ist.
Du hast bestimmt nur "localhost:3128" oder aenliches eingefuellt, aber in die Variable muss "http://localhost:3128/" gesetzt werden.
Guter Hinweis. cb@cboltz:~/mbox-archiv/HEAD> echo $http_proxy http://localhost:8080 Würde passen. Aber: cb@cboltz:~/mbox-archiv/HEAD> echo $HTTP_PROXY localhost:8080 Nach Änderung auf http://localhost:8080 funktioniert GET :-) Womit auch bewiesen wäre, dass GET $HTTP_PROXY und nicht $http_proxy auswertet... Gruß Christian Boltz -- Eine Katze hat einen Schwanz mehr als keine Katze. Keine Katze hat zwei Schwänze, also hat eine Katze drei Schwänze. [Bernd Brodesser in suse-linux]
participants (4)
-
Christian Boltz -
David Haller -
Dirk Eberhardt (deberhar) -
Peter Wiersig