POST Funktion beim "seite zurück" ausstellen

[Oli]

Hallo wiedermal,

ich habe das Problem, dass wenn ich eine POST action mache (also ein Formular), dass wenn ich auf der nächsten Seite bin, und dann im Browser "eine Seite zurück" gehe, gefragt werde, ob ich die POST Daten nochmals senden möchte.

Meine Frage: Lässt sich festlegen, dass wenn man im Browser eine Seite zurück geht, dass die POST Daten nicht erneut abgesendet werden.
Aber ich will das nicht im Browser festlegen, sondern Serverseitig. Also das es bei jedem user ausgestellt ist.

Falls mir jemand weiter helfen könnte wäre ich dankbar.

lg Oli

[Tom]

Hello,

Meine Frage: Lässt sich festlegen, dass wenn man im Browser eine Seite zurück geht, dass die POST Daten nicht erneut abgesendet werden.

Du kannst die Response auf den Post mit einem Redirection-Header belegen und die eigentliche Antwort dann dann nach dem Request durch Redirect aus der Session kramen.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Cybaer]

Hi,

Du kannst die Response auf den Post mit einem Redirection-Header belegen und die eigentliche Antwort dann dann nach dem Request durch Redirect aus der Session kramen.

?

Hast Du ein Beispiel parat, mit dem sich die Alertbox des erneuten Absendes serverseitig vermeiden läßt?

So wie ich dich verstehe, meinst Du folgendes:
1. Redirect mit Session
2. Auf der Zielseite die Session-Daten auswerten und Session schließen

Und dabei geht dann die Info für den Browser verloren, daß er Daten gepostet hat? Das Funktioniert? (Mal von der häßlichen SID im URL oder ggf. eigentlich unnötiger Nachfrage "Wollen Sie einen Cookie erlauben?" mal abgesehen.)

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Du kannst die Response auf den Post mit einem Redirection-Header belegen und die eigentliche Antwort dann dann nach dem Request durch Redirect aus der Session kramen.
Hast Du ein Beispiel parat, mit dem sich die Alertbox des erneuten Absendes serverseitig vermeiden läßt?

Nein, wenn der Browser erneut zu POSTen gedenkt, dann fragt er dabei nach. Ziel ist es jedoch, den ursprünglichen POST durch einen Redirect auf ein GET aus der History fern zu halten. Eine Session ist dabei nicht zwingend erforderlich, wenn man keine Daten benötigt, die sich nur aus dem POST-Request ergeben.

Beispielsweise hat man ein Formular zum Datensatz mit der ID foo auf einer Formularseite ausgegeben (GET edit.php?id=foo). Die geänderten Daten sendet man per POST-Request an den Server (POST edit.php?id=foo - gleiche URL, wegen Affenformular). Der schreibt sie weg und antwortet mit einem Redirect auf die Listendarstellung (von einer Auswahl) aller Datensätze (GET list.php) oder auch wieder dem Formular (GET edit.php?id=foo), je nachdem wie man seinen Anwendung gestaltet. Eine "alles bestens, keine Fehler"-Meldung halte ich im Gutfall für verzichtbar.

Problematisch wird es nur, wenn das Affenformular aufgrund von fehlerhaften Eingaben eine oder mehrere Runden drehen muss. Dann hat man zwar den fehlerfreien POST durch den Redirect eliminiert, die fehlerhaften Runden bleiben aber in der History erhalten. Wenn man die jedes Mal mit einem GET-Redirect abfangen möchte, muss man sich was ausdenken, wie man die Fehlermeldungen in die Antwort auf den Redirect-Request bringt. Eine Session wäre eine Möglichkeit, die Meldung in der URL zu übertragen eine weitere, wenn auch keine sehr schöne.

Und dabei geht dann die Info für den Browser verloren, daß er Daten gepostet hat?

Ja, die ursprünglichen Ziele eines mit einem normalen HTTP-Redirects beantworteten Requests landen nicht in der History. Nur HTML-Meta-Element-Redirects landen da.

(Mal von der häßlichen SID im URL oder ggf. eigentlich unnötiger Nachfrage "Wollen Sie einen Cookie erlauben?" mal abgesehen.)

Wenn man eine Daten verarbeitende Application vorliegen hat, die über "Gästebuch" hinausgeht, kann man schon mal eine Session-Akzeptanz auch bei Web-Ästheten einfordern.

echo "$verabschiedung $name";

[Cybaer]

Hi,

Ja, die ursprünglichen Ziele eines mit einem normalen HTTP-Redirects beantworteten Requests landen nicht in der History. Nur HTML-Meta-Element-Redirects landen da.

Ja, das war mir bewußt. Den Effekt auch zur Verhinderung dieses "POST-Effekts" zu nutzen, auf den Gedanken war ich *bewußt* noch nicht gekommen - obwohl: verwenden tue ich es eigentlich auch schon (s. Das Schwarze Loch des Internets - um geile URLs wird bei der Gelegenheit auch hier gebeten ;-)). Die Eingabe neuer URLs funktioniert genau nach diesem Prinzip - aber ehrlicherweise: eben unbewußt ... :)

Gruß, Cybaer

[Cybaer]

Hi,

Aber ich will das nicht im Browser festlegen, sondern Serverseitig. Also das es bei jedem user ausgestellt ist.

Ggf. ist ein JS-Workauround hilfreich: Einfach die Zielseite durch sich selbst replace()en. Damit sehen dann schonmal alle Surfer mit aktivem JS den Hinweis nicht mehr ...

Gruß, Cybaer

[oli]

danke.

aber wie, bzw wo baue ich diese replace() funktion dann ein?

lg

[Cybaer]

Hi,

aber wie, bzw wo baue ich diese replace() funktion dann ein?

In den HEAD der Ergebnisseite.

Schema: Serverscript verarbeitet POST-Daten. Wenn die Verarbeitung geklappt hat, wird HTML ausgegeben ("Danke! Bla Blubb"). Im HEAD dieses HTML-Dokuments wird das JavaScript plaziert: window.location.replace(window.location.href);

Hat das Serverscript keinen Daten bekommen (wird es also nicht via POST sondern direkt aufgerufen), dann wird zwar auch das HTML ausgegeben, aber ohne das JavaScript.

Folge: Serverscript verarbeitet POST-Daten, gibt HTML aus, bevor das HTML zu sehen ist, wird auf JS-Browsern die Seite neu geladen, diesmal ohne die JS-Weiterleitung -> Seite bleibt und wird angezeigt.

Aber: Ohne JS geht es halt auch - mit einem ähnlichen Schema.

Serverscript verarbeitet POST-Daten, macht aber keine Ausgabe, und leitet im Erfolgsfall mittels (vereinfacht) header('Location: http://www.example.org/ergebnis.php') auf sich selbst (oder andere, ggf. reine HTML-Seite) weiter. Funktioniert auf jedem Browser, da unabhängig von JS

Gruß, Cybaer