session_start(): Browser frieren ein!

[williamwallace]

Hi,

seit einigen Tagen läuft ein PHP-Script auf unserem Server nicht mehr,
allerdings komischerweise nur in Mac OS X-Browsern:

Ich rufe von einem Kontaktformular per header ("Location...") eine send.php auf, nachdem ich per session_start() eine Session angelegt habe.
Wenn in der send.php nun erneut ein session_start() aufgerufen wird, um die Session wieder aufzugreifen, frieren Mac IE, Safari & Firefox ein und nach 5 Minuten kommt ein Error 500?! Unter Windows läuft alles korrekt.

Hier Auszüge aus den Dateien:

Formular.php:

PHP-Code:
<?php 
session_start(); 
$_SESSION['session_email'] = $email; 
$_SESSION['session_name'] = $name; 

[...] 

header("Location: http://www.domain.de/sites/send.php"); 
?>




Send.php:

PHP-Code:
<?php 
session_start(); 

[...] 

mail ("Adresse","Anfrage",$var, $header); 
?>

Ich wäre sehr froh, wenn mir einer von Euch helfen kann.

Viele Grüße
Frank

 

[koli.bri]

Jetzt mal ganz blöd gefragt, wird vor dem session_start() etwas an den Browser zurückgegeben, also eine Ausgabe gemacht? Ein simples Leerzeichen vor dem ersten <?php reicht da schon...

Anonsten fällt mir Spontan nichts ein (auch wenn das normalerweise eine PHP-Meldung geben müsste)

gruß
Lukas

 

[b.legt210]

Fehler 500 kenne ich sonst eigentlich nur im Zusammenhang von "missratenen" .htaccess-Einstellungen.
Ich würde nach dem "header(location..)" auch mal ein exit; einfügen. So stellst du sicher, dass danach nichts mehr ausgeführt wird.
Bei einer Weiterleitung zu einem anderen Server (andere Domain) würde es mich doch schwer wundern, wenn Session-Variablen dort zur Verfügung stehen würden. Diese werden ja schließlich auf dem Server gespeichert und stehen damit nicht auf anderen Servern zur Verfügung. Wäre also die Frage:
Was willst du eigentlich machen??

Stephan

 

[Galanos]

Sehr merkwuerdig, dass das Problem Client-seitig entstehen soll.
Wenn du sagst, dass die Browser "einfrieren", meinst du dann, dass das Programm nicht mehr reagiert oder dass sie ewig keine Rueckmeldung vom Server bekommen?
Wird irgendwo in den Scripts auf Client-spezifische Daten (HTTP_USER_AGENT etc.) zugegriffen?
Ansonsten ist es mir unerklaerlich …

Willkommen im Forum

@b.legt210: Ich glaube, er bleibt auf seinem Server, schreibt die URL nur absolut. Oder?

 

[williamwallace]

Hallo Stefan,

Die Weiterleitung zielt auf eine Datei der selben Domain...
Es geht lediglich um ein Kontaktformular, das auf Vollständigkeit überprüft wird und falls alles in Ordnung ist, eine send.php aufgerufen wird, in der die Mail generiert wird.

Alles Wichtige wird zur Übergabe in session-Variablen gespeichert.

Abstrahiert würde aber allein das zweite session_start() zum Fehler führen. Wie gesagt, bis unter Max OS X läuft das Script fehlerfrei.

Viele Grüße
Frank

 

[Galanos]

Dann muss ich die bloede Frage stellen: Warum eine Session und eine zweite Datei (send.php)? Die Mail-Funktion kannst du doch in das Daten-Ueberpruefungsscript reinpacken und ausfuehren, wenn die Ueberpruefung erfolgreich verlaufen ist, oder?

 

[b.legt210]

Hi Frank,

wozu "springst" du denn dann auf eine neue Seite? oder aber: wozu das header("location..")?
Nach Überprüfen der Daten kannst du doch direkt die "Versende-Funktion" aufrufen.

Stephan

 

[williamwallace]

Das ist korrekt, hab dies gesplittet zur Übersichtlichkeit des Quellcodes.
Müsste aber doch auch für einen Mac ein Leichtes sein, eine Session nach Seitenwechsel wiederaufnehmen zu können.

Ich kann jetzt theroetisch, wie du schon sagst, das Problem durch Umstrukturierung umgehen, das würde mir allerdings keinen Seelenfrieden bringen...

 

[wegus]

session_start();
$_SESSION['session_email'] = $email;
$_SESSION['session_name'] = $name;

[...]

header("Location: http://www.domain.de/sites/send.php");

Das geht so nicht! Wenn doch müßte es Zufall sein!!!

header("Location") bricht zu undefinierter Zeit das parsen einer Seite ab um den REDIRECT auszuführen, weitere HTTP-Header werden nicht zuverlässig abgearbeitet, wie man hier wohl sieht! HTTP-Redirect & Session führt immer zu trouble!

 

[Galanos]

Wenn es dir nur um Uebersichtlichkeit des Quellcodes geht, schreibe doch die Mail-Funktion in eine gesonderte Datei und include() sie in das Formular.

 

[williamwallace]

Ja, das könnte ich alles machen...
und dennoch wüsste ich nicht, warum Mac OS X mit Sessions rumzickt.

Es könnte ja genauso gut ein Projekt sein, bei dem ich auf Sessions angewiesen wäre....

 

[dannycool]

Mac OS X? Ein HTTP-Fehler 500 kann nur serverseitig entstehen. Das schlimmste, das ein Browser machen kann, ist, falsche Daten zu liefern - davon darf sich aber der Server nicht zum Absturz bringen lassen!

 

[wegus]

und dennoch wüsste ich nicht, warum Mac OS X mit Sessions rumzickt.

weil es mit den Sessions nichts zu tun hat! Es läuft der gleiche Apache, wie unter irgendwelchen UNIXen auch! HTTP 500 wird auch nur vom Apache-Prozeß generiert! Ich denke das starten der Session ( was ja eine Kommunikation auslöst) und der HTTP REDIRECT shreddern die HTTP-Header und somit führt der dann unvollständige Aufruf zu einem Serverfehler. Mit Mac OS hat das gar nichts zu tun - Du hattest bisher schlicht Glück das die Kombination lief!

 

[Galanos]

Dann moechte ich meine Frage nochmal stellen:

Wird irgendwo in den Scripts auf Client-spezifische Daten (HTTP_USER_AGENT etc.) zugegriffen?

 

[williamwallace]

Und dennoch hab ich hier 3 Macs mit X, 2 mit OS 9.2 und 4 Windows Maschinen.

Die 6 Rechner mit Windows und 9.2 laufen das Script durch, die beiden Mac OS X frieren ein.

Liefert der Server vielleicht etwas zurück, was X quersitzt?


Zu deiner Frage: nein!

 

[wegus]

gut, ich frage anders: Wo im Ablauf des HTTP-Protokolls kommt denn das OS zum tragen? Es liefert doch nur IP-Pakete aus, für welches Protokoll ist doch egal!

Bei OS 9.2 denke ich zunächst an einen sicher sehr alten Apache und sicher auch an altes PHP. Das Session-Handling hat sich, wie Vieles in PHP, von Version zu Version sehr verändert. Vielleicht liegt es an alten/unzulässigen session-Befehlen!?

 

[Galanos]

Darfst/kannst/moechtest du die URL rausruecken? Wuerd mir gern mal anschauen, was mein Safari da macht.

Edit: Irgendwie werde ich dauernd ueberlesen … Ich faerbe mal meine Frage ein.

 

[williamwallace]

Ich glaube, wir reden aneinander vorbei.

Das Script liegt auf einem Linux-Apache-Web-Server, der total unabhängig ist.

Mac OS X, Mac OS 9.2 und Windows sind alle nur Clients, sie greifen auf ein und den selben Server zu...

 

[wegus]

ah o.k.!

Abgesehen von der von mir geschilderten Problematik, ist die Location-URL wirklich absolut? Relative können ebenfalls Fehler generieren UND diese Fehler wären Browser-Abhängig. Mehr dazu:

http://de2.php.net/manual/de/function.header.php

Welche Browser verwendest Du unter Mac OS?

 

[dannycool]

Das Script liegt auf einem Linux-Apache-Web-Server, der total unabhängig ist.

Der HTTP-Code 500 heißt "Internal Server Error". Vielleicht steht etwas im Logfile? Der Client hat damit jedenfalls nichts zu schaffen, ein interner Fehler ist immer ein Problem des Servers. Fehler, die vom Client verursacht werden können, haben andere Nummern.