post, redirect, browser history

[phoenix20]

aus einem alten thread von hier:
...
book.php: zeigt das Gästebuch an.
eintrag.php: trägt einen Eintrag ein
und führt dann einen Redirect auf eine Status-Seite
( header('Location: http://www.domain.de/gb_status.html') ) durch
...

Mich würde interessieren warum das funktioniert, bzw. warum der Browser 'POST eintrag.php' nicht in die history nimmt, sondern nur 'GET gb_status.html' ?
Die andere Frage ist noch, wie die Daten (im Beispiel) von eintrag.php nach gb_status.html kommen bzw ob $_SESSION und $_GET richtig sind. Und wie die Daten allenfalls von gb_status.html nach book.php kommen, falls user das Formular nochmals sehen will.
Gibt es dafür ein Tutorial?

[wahsaga]

Re: post, redirect und forward/backward

Original geschrieben von phoenix20
Mich würde interessieren warum das funktioniert, bzw. warum der Browser 'POST eintrag.php' nicht in die history nimmt, sondern nur 'GET gb_status.html' ?

Weil's genau so gedacht ist :-)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Der normale Redirect, den PHP beim Location-Header auslöst, ist einer mit HTTP Status Code 302 Found.

Der ist eigentlich nicht der passendste, 303 See Other wäre angebrachter:

303 See Other
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource.

Aber ...

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.

[phoenix20]

Danke, immerhin steht beim 303 auch noch:

The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

Der 302er ist ziemlich das Gegenteil davon....

Bei beiden steht vorläufig nichts dass der POST davor in der History des User Agent vergessen wird und in den mainstream php-Texten ist nichts von dieser Technik.... scheint sich um einen Geheimtipp zu handeln....wie noch viel anderes....

Ich würde einfach mal gerne einen ganzen Text dazu lesen.

[wahsaga]

Original geschrieben von phoenix20
Danke, immerhin steht beim 303 auch noch:

Ja, die 303-Antwort selber darf nicht gecached werden - die Ressource, auf die sie verweist, aber gegebenenfalls.

Der 302er ist ziemlich das Gegenteil davon....

Nein, eigentlich nicht.
Bei 302 sollte der Client auch bei zukünftigen Anfragen immer wieder mit dem Original-URL anfragen. Es sei denn, ihm wird geagt, die 302-Antwort wäre für eine bestimmte Zeitspanne cacheable - dann darf er während dieser gleich die Ressource anfordern, auf die temporär umgeleitet wurde.

Bei beiden steht vorläufig nichts dass der POST davor in der History des User Agent vergessen wird

Nun ja, Browser sind ja auch nur eine Teilgruppe von dem, was HTTP als Clients ansieht. Andere Clients haben so etwas wie eine "History" vielleicht gar nicht. Sich darum zu kümmern, wie der Client seinem Nutzer bereits früher aufgerufene Adressen ggf. zum raschen Wiederaufruf zur Verfügung stellt, ist nicht Aufgabe von HTTP.

[phoenix20]

Original geschrieben von wahsaga
Nun ja, Browser sind ja auch nur eine Teilgruppe von dem, was HTTP als Clients ansieht. Andere Clients haben so etwas wie eine "History" vielleicht gar nicht. Sich darum zu kümmern, wie der Client seinem Nutzer bereits früher aufgerufene Adressen ggf. zum raschen Wiederaufruf zur Verfügung stellt, ist nicht Aufgabe von HTTP.

Lieber keine Antwort als so eine. Geht doch mit keinem Wort auf das wesentliche Geschehen ein, dass eine POST-Uri in der history durch die redirectede ersetzt wird und was sonst noch in diesem Zusammenhang gelesen werden könnte. Es ist schade, dass modis nicht auf die Ignorierliste gesetzt werden können.

[onemorenerd]

Schlecht gefrühstückt?
Wahsaga kommentiert deine Anmerkung, dass etwas nicht im RFC steht zurecht und überaus sachlich damit, dass dieses RFC sich eben mit HTTP beschäftigt und nicht der Implementation von Browsern.

[phoenix20]

ich verleg den thread in ein anderes subforum. Es geht um die History und die redirect-headers und dergleichen. rfc 302/303 spielt sicher eine rolle aber sogar für mich reicht's nicht.

[phoenix20]

post, redirect, browser history

aus einem alten thread von hier:
...
book.php: zeigt das Gästebuch an.
eintrag.php: trägt einen Eintrag ein
und führt dann einen Redirect auf eine Status-Seite
( header('Location: http://www.domain.de/gb_status.html') ) durch
...

Mich würde interessieren warum das funktioniert, bzw. warum der Browser 'POST eintrag.php' nicht in die history nimmt, sondern nur 'GET gb_status.html' ?
Die andere Frage ist noch, wie die Daten (im Beispiel) von eintrag.php nach gb_status.html kommen bzw ob $_SESSION und $_GET richtig sind. Und wie die Daten allenfalls von gb_status.html nach book.php kommen, falls user das Formular nochmals sehen will.
Gibt es dafür ein Tutorial?

[mrhappiness]

Re: post, redirect, browser history

Original geschrieben von phoenix20
Mich würde interessieren warum das funktioniert, bzw. warum der Browser 'POST eintrag.php' nicht in die history nimmt, sondern nur 'GET gb_status.html' ?

Auch wenn du's nicht hören willst: Das liegt daran, dass der von dir verwendete Browser (Client) die HTTP-Statuscodes eben so interpretiert.

Dein Browser sagt: Wenn der Server mir beim Anfordern der Seite eintrag.php sagt, dass ich statt dessen gb_status.html anfordern soll, dann nehme ich die Seite eintrag.php - die ich ja sowieso nicht anzeigen kann - auch nicht in meine History auf

Daran, dass dein Browser das sagt, kannst du nichts ändern. Punkt.

Die andere Frage ist noch, wie die Daten (im Beispiel) von eintrag.php nach gb_status.html kommen bzw ob $_SESSION und $_GET richtig sind. Und wie die Daten allenfalls von gb_status.html nach book.php kommen, falls user das Formular nochmals sehen will.
Gibt es dafür ein Tutorial?

Wie meinen?

Welche Daten von woher sollen wann wo angezeigt werden?

[mrhappiness]

Hier geht's weiter: http://php-resource.de/forum/showthr...&postid=453492

[onemorenerd]

Re: post, redirect, browser history

Original geschrieben von phoenix20
Die andere Frage ist noch, wie die Daten (im Beispiel) von eintrag.php nach gb_status.html kommen

eintrag.php: trägt einen Eintrag ein

... es müssen keine Daten übertragen werden. Falls es doch sein müßte, könnte man sie per Session oder URL-Parameter weitergeben.

Und wie die Daten allenfalls von gb_status.html nach book.php kommen

Das muß nun wirklich nicht sein, book.php zeigt nur an, was schon im GB steht.

falls user das Formular nochmals sehen will.

Ja auch das zeigt book.php an. Wieso sollte der User es nicht sehen?

Ich habe das Beispiel nämlich so verstanden:
book.php gibt das ganze GB aus und eine Form mit action="eintrag.php".
eintrag.php schreibt die übermittelten Formularwerte ins GB und leitet auf gb_status.html weiter.
gb_status.html ist eine statische Seite mit "Danke" oder sonstwas. Sie kann übergebene Daten gar nicht verarbeiten.

Interessiert dich der Zusammenhang von HTTP-Redirects und Datenübergabe nur im Zusammenhang mit diesem Beispiel oder allgemein?

[wahsaga]

@phoenix20: Deine absolut arrogante Antwort ist mir doch jetzt erst mal einen temporären *ban* für eine Woche Wert.

[phoenix21]

das ist mir schnuppe und zur sache, es interessiert mich allgemein.

zb habe ich einen link .....?cmd=delete

der ja auch gegen replay geschützt werden müsste. die grösste replay-Quelle ist nicht der böse trojaner oder google, sondern forward/backward, die zweitgrösste die history.

[phoenix22]

wahsaga macht natürlich mit den bans damit zuerst mal das thread-Thema kaputt. Für alle.

vermutlich sitzt er im Gefängnis .