nicht angemeldet
Browser-History: Kein autom. no-cache bei POST
Hallo!
Gibt es eine Möglichkeit, das man im Browser mit der Zurück-Schaltfläche eine Datei aufrufen kann, an die per POST Daten geschickt wurden?
Das Problem: Ich habe ein mehrstufiges Bestellformular, welches aus 3 php-Scripten mit je einem Forumlar besteht, die eingegebenen Daten werden immer per POST an das nächste Script geschickt. Das doofe, wenn man jetzt im Browser nochmal ein Formular zurück möchte, kommt immer die Fehlermeldung, das die Seite nicht mehr aktuell ist, so dass man manuell "aktualisieren" klicken muß, damit die POST-Daten erneut gesendet werden, und die Seite ausgegeben wird.
Das ist sehr unschön. Die einzige mir bekannte Möglichkeit dieses zu umgehen ist die Übertragung der Daten per GET, aber dann stehen die Daten in den URLs, Logs... was nicht wirklich erstrebenswert ist. Außerdem ist der GET-Request in Anzahl der Zeichen begrenzt.
Kann man das evtl durch entsprechende Header in ALLEN Browsern unterbinden? Leider kenne ich nur die Header, die genau das Gegenteil bewirken:
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Datum der
Vergangenheit
header ("Last-Modified: " . gmdate ("D, d M Y H:i:s") . " GMT");
// immer geändert
header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header ("Pragma: no-cache"); // HTTP/1.0
Ideen hätte ich zwar, aber das ist mehr Raterei. OK, das Ablaufdatum könnte in der Zukunft liegen, und das Last-Modified ein festes Datum in der Vergangenheit, wie müßten die beiden letzten lauten?
Vielen Dank!
Grüße
Andreas
-
Gibt es eine Möglichkeit, das man im Browser mit der Zurück-Schaltfläche eine Datei aufrufen kann, an die per POST Daten geschickt wurden?
Diese "Zurück-Schaltfläche" ist Browserabhängig, was passiert, wenn man sie nutzt, ist alleine Sache des Browsers, es ist nicht genormt und dementsprechend kann man es auch nicht beeinflussen.
Das Problem: Ich habe ein mehrstufiges Bestellformular, welches aus 3 php-Scripten mit je einem Forumlar besteht, die eingegebenen Daten werden immer per POST an das nächste Script geschickt. Das doofe, wenn man jetzt im Browser nochmal ein Formular zurück möchte, kommt immer die Fehlermeldung, das die Seite nicht mehr aktuell ist, so dass man manuell "aktualisieren" klicken muß, damit die POST-Daten erneut gesendet werden, und die Seite ausgegeben wird.
Wenn die Daten tatsächlich längere Zeit aktuell bleiben, kannst du 'Cache-Control: public' und ein 'Expires:' für einem bestimmten Punkt in der Zukunft senden, damit machst du die Antwort prinzipiell zwischenspeicherbar, was die Benutzeragenten machen, bleibt allerdings von ihnen und anderen Faktoren abhängig. Alternativ wäre, Status 303 mit entsprechender Seitenangabe zu senden, sprich, eine quasi-Weiterleitung auf eine zwischenspeicherbare Resource.
Das ist sehr unschön. Die einzige mir bekannte Möglichkeit dieses zu umgehen ist die Übertragung der Daten per GET, aber dann stehen die Daten in den URLs, Logs... was nicht wirklich erstrebenswert ist. Außerdem ist der GET-Request in Anzahl der Zeichen begrenzt.
Nein, das ist er nicht. Einige Implementationen begrenzen ihn künstlich, das dürfen sie aber nicht. GET kannst du im übrigen nur dann verwenden, wenn die Anfrage keine Nebeneffekte hervorruft, genau dann solltest du allerdings auch GET verwenden.
Kann man das evtl durch entsprechende Header in ALLEN Browsern unterbinden?
Nichts, aber auch gar nichts funktioniert in "ALLEN" Browsern zuverlässig.
Vielleicht solltest du einfach nochmal nachdenken, ob du das ganze so überhaupt sinnvoll implementiert hast.
-
Hallo!
Diese "Zurück-Schaltfläche" ist Browserabhängig, was passiert, wenn man sie nutzt, ist alleine Sache des Browsers, es ist nicht genormt und dementsprechend kann man es auch nicht beeinflussen.
Naja, die Browser müssen sich ja auch nach Standards richten, um überhaupt html zu verstehen und über http komunizieren zu können. Mir ist bekannt das das einige besser, andere schlechter und keiner perfekt macht, aber in einem gewissen Rahmen sollte man ja den Browser noch beeinflussen können, oder?
Wenn die Daten tatsächlich längere Zeit aktuell bleiben, kannst du 'Cache-Control: public' und ein 'Expires:' für einem bestimmten Punkt in der Zukunft senden, damit machst du die Antwort prinzipiell zwischenspeicherbar, was die Benutzeragenten machen, bleibt allerdings von ihnen und anderen Faktoren abhängig. Alternativ wäre, Status 303 mit entsprechender Seitenangabe zu senden, sprich, eine quasi-Weiterleitung auf eine zwischenspeicherbare Resource.
Es geht nicht um "längere Zeit aktuell". Sagen wir mal ich habe 3 Seiten. Auf der ersten Seite steht ein Formular, in das die Adresse eingegeben wird, das Forumlar wird abgeschickt und die Daten werden an die 2. Seite geschickt, auf der sich ein weiteres Formular befindet, in dem man die Zahlungsweise wählt. Auf der 3. Seite werden alle Daten angezeigt und die Bestellung bestätigt.
Jetzt hat ein user die Adresse eingegeben, auf "weiter" geklickt, hat eine Zahlungsweise gewählt und wieder "weiter", da fällt ihm ein, er will doch lieber anders bezahlen, klickt auf "zurück" und schwupp sind die Daten weg. Erst mach aktualisieren ist es wieder da, halt unschön wie ich finde. Es geht nicht um die Aktualität der Daten, die sind ja eh vom user eingegeben, sondern um das umständliche/unnötige Aktualisieren!Das ist sehr unschön. Die einzige mir bekannte Möglichkeit dieses zu umgehen ist die Übertragung der Daten per GET, aber dann stehen die Daten in den URLs, Logs... was nicht wirklich erstrebenswert ist. Außerdem ist der GET-Request in Anzahl der Zeichen begrenzt.
Nein, das ist er nicht. Einige Implementationen begrenzen ihn künstlich, das dürfen sie aber nicht. GET kannst du im übrigen nur dann verwenden, wenn die Anfrage keine Nebeneffekte hervorruft, genau dann solltest du allerdings auch GET verwenden.
Ja, kann sein das es so sein sollte, aber wenns nunmal nicht in alle Browsern geht?
Kann man das evtl durch entsprechende Header in ALLEN Browsern unterbinden?
Nichts, aber auch gar nichts funktioniert in "ALLEN" Browsern zuverlässig.
Klar, aber vielleicht gibt es eine Sammlung von headern, die beim Netscape > 4.5 und IE > 5.0 bewirken, das die Aktualisierung unterdrückt wird - war auch nur ein Gedanke.
Vielleicht solltest du einfach nochmal nachdenken, ob du das ganze so überhaupt sinnvoll implementiert hast.
Na wie machst Du das denn besser? Ich denke die meisten großen Shops machen das nicht anders?! Also die einzige Möglichkeit die Zahlungsweise mit der Adresse auf ein Forumular zu nehmen, oder per GET? Schade...
Grüße
Andreas-
Klar, aber vielleicht gibt es eine Sammlung von headern, die beim Netscape > 4.5 und IE > 5.0 bewirken, das die Aktualisierung unterdrückt wird - war auch nur ein Gedanke.
Ich habe dir gesagt, was RFC 2616, sprich HTTP/1.1 vorsieht. Das kannst du ausprobieren. Wenn das nicht zum gewünschten Resultat führt, kannst du POST nicht verwenden, musst also etwas anderes, grundlegendes ändern.
Vielleicht solltest du einfach nochmal nachdenken, ob du das ganze so überhaupt sinnvoll implementiert hast.
Na wie machst Du das denn besser? Ich denke die meisten großen Shops machen das nicht anders?!
Weisen die dasselbe Problem auf? Wenn ja, seis drum, wenn nein, gucken wie die das umgesetzt haben und ggf. nachmachen. *Ich* mache sowas gar nicht.
-
Hallo Andreas,
ich halte das so für den völlig falschen Weg.
Solange der Client sich im Bestellprozess befindet, sollte er GAR KEIN GELEGENHEIT haben, den Zurück-Button zu benutzen. Bau ihm eine eigene Navigationsmöglichkeit ein. Und da kannst Du dann mit einem Post die Daten wieder vom Server holen und anzeigen.
Der Fairness halber und um dem Gesetz genüge zu tun (!!!) sollte man vorher kurz erklären, wie der Bestellprozess abläuft. Mach einfach ein paar Screenshots von den Seiten und zeige sie (natürlich verkleinert) mit Erläuterungen auf einer Startseite zum Bestellprozess. Dort klärst Du den Kunden über sein Widerrufsrecht, sein Rückgaberecht, etc auf, erklärst ihm, dass seine Daten gespeichert werden, grüßt Herrn Gravenreuth ganz lieb und machst darauf aufmerksam, dass während des Bestellprozesses NICHT die Browsernavigation genutzt werden darf und deshalb solange (zur Erinnerung) ausgeschaltet wird. Schließlich gibt es für die ganz Harten immer noch die rechte Maustaste und das Kontextmenu. Das musst Du serverseitig handlen, was mit den ja schon von Dir beschriebenen Wiederholungsaufrufen geschieht.
Ohne JavaScript wird es also nicht gehen. Ob das eingeschaltet ist, kannst Du ja auf der Erklärungsseite per "Kombilink" testen. Wenn es nicht eingeschaltet ist, dann "tschüss-Seite".
Ich spreche jetzt mal als Kaufmann:
Das Gesetz schreibt bereits soviele Einschränkungen vor, dass Du überall dort, wo es noch zulässig ist, die Regeln selbst bestimmen musst.Der direktive Weg erscheint mir hier der bessere zu sein.
Liebe Grüße
Tom
-
Hallo!
ich halte das so für den völlig falschen Weg.
Was ist denn Deiner Meinung nach besser? GET oder Zusammenfasung auf eine Seite?
Solange der Client sich im Bestellprozess befindet, sollte er GAR KEIN GELEGENHEIT haben, den Zurück-Button zu benutzen. Bau ihm eine eigene Navigationsmöglichkeit ein. Und da kannst Du dann mit einem Post die Daten wieder vom Server holen und anzeigen.
Ich hole gar nichts per POST vom Server. Das Problem tritt auf, wenn man im IE eine Seite in der Browser-History aufruft, an die zuvor Daten an dieses Script vom Browser an den Server per POST gesendet wurden. Warum sollte man dem Client keine Gelegenheit dazu geben? Unterebinden kann man es schlichweg nicht! Und nur Javascript zu akzeptieren finde ich etwas arm!
Der Fairness halber und um dem Gesetz genüge zu tun (!!!) sollte man vorher kurz erklären, wie der Bestellprozess abläuft. Mach einfach ein paar Screenshots von den Seiten und zeige sie (natürlich verkleinert) mit Erläuterungen auf einer Startseite zum Bestellprozess.
Naja, ob das sein muß? Habe ich noch nirgends gesehen und machen sich jetzt alle strafbar?
Dort klärst Du den Kunden über sein Widerrufsrecht, sein Rückgaberecht, etc auf, erklärst ihm, dass seine Daten gespeichert werden,
Das ist vorgeschrieben!
grüßt Herrn Gravenreuth ganz lieb und machst darauf aufmerksam, dass während des Bestellprozesses NICHT die Browsernavigation genutzt werden darf und deshalb solange (zur Erinnerung) ausgeschaltet wird. Schließlich gibt es für die ganz Harten immer noch die rechte Maustaste und das Kontextmenu. Das musst Du serverseitig handlen, was mit den ja schon von Dir beschriebenen Wiederholungsaufrufen geschieht.
aber WARUM? Was ist so problematisch daran, wenn jemand die Möglichkeiten seines ihm vertrauten Browser verwenden möchte? Es funktioniert ja mit GET, oder mit nur einer Eingabemaske.
Ohne JavaScript wird es also nicht gehen. Ob das eingeschaltet ist, kannst Du ja auf der Erklärungsseite per "Kombilink" testen. Wenn es nicht eingeschaltet ist, dann "tschüss-Seite".
Was meinst Du mit "kombiklick"? Wie funktioniert das?
Ich spreche jetzt mal als Kaufmann:
Das Gesetz schreibt bereits soviele Einschränkungen vor, dass Du überall dort, wo es noch zulässig ist, die Regeln selbst bestimmen musst.Ja, aber was bietet mir das hier für Vorteil, außer das ich die Anzahl meiner Kunden künstlich dezimiere? Nicht sehr kaufmännisch wie ich finde!
Der direktive Weg erscheint mir hier der bessere zu sein.
naja...
Grüße
Andreas
-
-
-
-
Hallo Björn,
Wenn die Daten tatsächlich längere Zeit aktuell
bleiben, kannst du 'Cache-Control: public'bist Du sicher, daß für einen so personalisierten
Vorgang wie eine Bestellung eine Zwischenspeicherung
in Proxy-Servern wünschenswert ist?Wäre "Cache-Control: private" hier nicht angemessener?
Viele Grüße
Michael
-
-
Moin!
Gibt es eine Möglichkeit, das man im Browser mit der Zurück-Schaltfläche eine Datei aufrufen kann, an die per POST Daten geschickt wurden?
Wenn du den falschen Browser benutzt, dann geht es nicht. Mein Browser (Opera) kann das ohne Probleme. Er läßt sich übrigens auch nicht so verbiegen, daß das Zurückblättern verhindert werden kann (Versuche mit den dir bekannten Headern sind sinnlos). Aus dieser Diskrepanz solltest du erkennen, daß dein Vorhaben allein deswegen zum Scheitern verurteilt ist, weil du dich auf die Browser nicht verlassen kannst.
Laut irgendeiner RFC (dessen Nummer mir gerade nicht einfällt) ist das Verhalten von Opera, also genau das, was du willst, korrekt. Mit "Vor" und "Zurück" soll man die Seiten, ohne den Server zu befragen, nochmal so sehen, wie man sie verlassen hat. Das ist bei Formularen der ausgefüllte Zustand. Macht Opera ganz prima so. Wenn der IE oder Netscape 4 das nicht so machen, liegts an der mangelhaften Umsetzung dieser RFC - und das kannst du nicht beeinflussen, weil's im Browser so einprogrammiert ist.
- Sven Rautenberg
-
Hi Sven!
Du hast natürlich zu 100% Recht - aber davon kann ich mir leider nichts kaufen! IE und NN4 machen grob geschätzt 80% oder mehr der Besucher aus und danach habe ich mich zu richten. Ich finde es auch traurig.
Ich schwanke gerade zwischen beibehalten der Seiten und Umstellung auf GET, und Zusammenfassen der ersten beiden Seiten und das dann mit Anker oder so machen. Javascript will ich auf alle Fälle vermeiden.
Was meinst Du?Grüße
Andreas-
Hi Sven!
Ich schwanke gerade zwischen beibehalten der Seiten und Umstellung auf GET, und Zusammenfassen der ersten beiden Seiten und das dann mit Anker oder so machen. Javascript will ich auf alle Fälle vermeiden.
Was meinst Du?Was hälst du von einem Tab-Formular. Wenn du drei Formularseiten hast, dann kannst du als Navigation doch genausogut drei Navigationspunkt anbieten, die auf die jeweiligen Seiten gehen. Auf diese Weise kommt man von jeder Seite zu jeder anderen Seite.
Die dummen User kriegen einen deutlichen "weiter..."-Submitbutton. Und die Javascript-User kriegen (möglicherweise) alle drei Seiten in einer, wobei zwei Seiten per Layer versteckt sind und wechselweise angezeigt werden. Schätzungsweise könnte das funktionieren, solange kein Netscape 4 im Spiel ist (der denkt über Layer ja etwas differenziert, was die Zugehörigkeit zum eigenen Dokument angeht). Ausprobieren ist angesagt. Was schickt Netscape 4, wenn im Formular Layer mit Formularfeldern enthalten sind. Oder muß man, da Javascript ja ohnehin aktiv sein muß, die Formularinhalte in Hidden-Felder retten?
Der einfachste Fall wäre, einfach einen "zurück"-Submitbutton einzufügen. Solange du jedenfalls dynamische Serverunterstützung hast, hast du im Grunde genommen nur sehr wenig Probleme - du mußt halt die Daten behalten und möglicherweise immer wieder mit ausliefern.
Ansonsten kann es auch einfach helfen, statt drei Seiten _eine_ zu machen. Dann kann man scrollen, anstatt zu submitten. :)
- Sven Rautenberg
-
-