das F5 problem

Hallo!

Jedoch erfolgt eine Fehlermeldung:

Warning: Cannit modify header information - headers already sent by (output started at .... user_online.php:8) in profil.php line 1789
Es macht zwar keinen Sinn vor der sofortigen Weiterleitung mittel header() ein echo auszugeben, aber trotzdem ist es möglich:
PHP:
<?php
ob_start();

echo "Hallo Welt!";

header("Location: http://www.tutorials.de");

ob_end_flush();
?>
Siehe auch die Anmerkungen und Kommentare im PHP-Manual zu header().

Gruss Dr Dau
 
Hi,

warum muss man da überhaupt F5 drücken oder eine Weiterleitung machen? Wenn Du im Script zuerst die gesendeten Daten einträgst und erst danach die Daten für die Anzeige ausliest, wie sich das gehört, dann gibt es das Problem erst gar nicht. Für so etwas braucht man keine Weiterleitungen oder F5...

LG
 
Es kommt drauf an.....
Wenn die zu verarbeitenden Daten aus z.B. einem Formular kommen, muss natürlich weitergeleitet werden (also das Formular abschicken). ;)
Nun leitet das Formular aber per GET oder POST weiter..... und auf der Seite zu der man weitergeleitet wurde kann man fleissig F5 drücken..... und jedesmal werden die Daten erneut verarbeitet. ;)
Wenn man per header() nach der Datenverarbeitung z.B. wieder zum Formular weiterleitet, kann man so oft wie man will F5 drücken..... das Formular müsste jedesmal erneut abgesendet werden.
 
Hi,

ich glaube, das hat er noch gar nicht als Problem erkannt, sondern nutzt das im Moment als Featurebug. ^^
Ich habe ihn so verstanden, dass er nach Absenden des Formulars die gerade eingetragenen Daten gar nicht sehen kann, sondern dafür F5 drücken muss.

Abgesehen davon würde ich wegen der Reload-Problematik nicht unbedingt gleich zur Weiterleitung greifen. Das könnte man z.B. auch mit einer Session und einem generierten Token lösen.

LG
 
Hi Alex,

Doch doch. Nach einem Post sollte man schon ein Redirect machen.

Post-Redirect-Get Pattern

ich kenne das Problem wohl. Ich finde die Methode trotzdem unschön. Vor allem bekommt man das mit einer Session und so einem Token auch besser in den Griff:

The PRG pattern cannot solve every way of duplicate form submission. Some known duplicate form submissions that PRG cannot solve are:

* if a web user goes back to the web form and resubmits it.
* if a web user clicks a submission button multiple times before the server response loads.
* if a web user refreshes before the initial submission has completed because of server lag, resulting in a duplicate HTTP POST request in certain user agents.

Diese 3 Probleme hat man damit schon mal nicht mehr. Ist das Token verbraucht, werden die Post-Daten einfach ignoriert.

LG
 
Zurück