Dokument nicht mehr aktuell bei Browser-Zurück (Browserfehlermeldung)

[godlike]

Hey,

ich habe ein kleines Problem. Habe eine Webseite geschrieben bei der man sich diverse Produkte zusammen klicken kann. Diese werden alle in Sessions gespeichert. Nun kommt man am Ende auf eine Bestellseite in der alles noch mal aufgelistet ist. Funktioniert alles prima. Nur wenn ich von der zweiten Seite, also da wo alles noch mal aufgelistet ist, per Browser zurück zur ersten Seite springen möchte erhalte ich folgende Fehlermeldung:

Die Webseite ist abgelaufen

Wahrscheinlichste Ursache:

• Die lokale Kopie der Webseite ist nicht mehr aktuell. Die Website erfordert daher, dass Sie sie erneut herunterladen.

Habe nun mit Cache-Control: max-age versucht dieses Problem in den Griff zu bekommen. Irgendwie funktioniert es, aber nich zu 100%. Jedes fünfte bis zehnte mal erscheint trotzdem dieser Fehler.

Habe Cache-Control: max-age auf beiden Seiten eingebaut. Theoretisch sollte es doch reichen, wenn der Aufruf auf der Seite auftaucht, auf die ich per Browser zurück gehe. Oder?

Gruß godlike

 

[epiphora]

Willst Du denn wirklich, dass die Seite gecacht wird? Logischer wäre doch eigentlich, wenn sie neu geladen würde. Daher würde ich eher so einen Header schicken:

Cache-Control: no-cache, must-revalidate

Außerdem solltest Du sicherstellen, dass der Cache bei Deinen weiteren Tests leer ist. Wenn sich nämlich noch eine Kopie der Seite im Cache befindet, kann man ja nicht voraussagen, ob Deine zukünftigen Tests nun erfolgreich sind, oder nicht.

 

[godlike]

Von meiner Warte aus kann die Seite gerne gecacht werden. Kehrt der User von der Übersicht auf die Seite zurück, auf der er die Auswahl ändern kann, so ändert sich ja erst mal nichts. Es sind noch immer die Selben Produkte ausgewählt. Ändert er jetzt seine Auswahl wird über den Submit-Button die Session sowieso aktualisiert bzw. überschrieben. Ist soweit auch getestet und funktioniert.

bei no-cache must-revalidate habe ich dann ja erst recht das Problem das die Seite nicht aus dem Cache kommen kann, sprich die Fehlermeldung angezeigt wird. Oder wie meinst du das genau?

Dachte das der Eintrag (Cache für 600 Sekunden speichern) genau die Fehlermeldung umgeht.

Gruß godlike

 

[epiphora]

Achso, na gut, eine Fehlermeldung sollte es dann natürlich nicht geben. Ich dachte, die Eingaben würden in der Session gespeichert und würden erst würden lediglich fehlerhafte Eingaben bemängelt, die chronologisch vor der aktuellen Seite hätten eingegeben werden müssen.

 

[godlike]

Ne, im Prinzip hast du eine Seite auf der du verschiedene Produkte wählen kannst (Seite 1). Am Ende gehst du über einen Submit-Button zur Übersicht (Seite 2). Wenn man nun von der Seite 2 mit der zurück Option zur Seite 1 gehst ändert sich ja nix an den in den Sessions gespeicherten Produkten. Nur die Fehlermeldung nervt da. Angekommen auf der Seite 1 kann man dann ja ohne Probleme die Produkte anders wählen. Sobald ich den Submit zur zweiten Seite nutze ändern sich die Sessions ja dementsprechend.

 

[Coca-Cola]

Hmm, den Cache brauchst du doch gar nicht, wenn eh alles in Sessions steht, oder?
Die Meldung sagt ja auch, dass die Seite neu geladen werden soll.
Ich würde es mal damit probieren:

[src=html4strict]<meta http-equiv="expires" content="0">[/src]

 

[Kugelfisch]

Wurden die Seite, auf welche du zurückkehren möchtest oder die Zielseite ursprünglich per POST angefragt? Tritt das Problem in verschiedenen Browsern gleichermassen auf?

 

[godlike]

@Coca-Cola:
Ok, muss ich morgen mal testen, danke für den Hinweis.

@Kugelfisch:
Bin mir zu 98% sicher das es per POST übergeben wird. Andernfalls wären die Variablen ja an der URI. Und das sehe ich nicht. Also POST. Das Problem trat in allen Browsern auf. IE, FF und Chrome. Irgendwie hat sich das ganze aber gebessert seit ich Cache-Control: max-age auf Seite 1 UND Seite 2 verwende. Seither trat das Problem so nicht mehr auf. Ich teste das aber noch mal eingehend...

 

[godlike]

Ok, hab noch etwas getestet. War die letzten Tage aber nicht auf der Arbeit, darum erst jetzt das Feedback.

Glaube auch den Grund gefunden zu haben an was es konkret liegt bzw. wann die Fehlermeldung auftaucht.

- Ich stelle mir also ein Angebot auf Seite 1 zusammen, gehe dann über einen Button auf die Seite 2 wo ich noch mal eine Auflistung meiner Posten bekomme. Die Daten werden hier per POST übergeben.

- Gehe ich jetzt mit dem Browser-Zurück-Button auf Seite 1 kommt kein Fehler, die Meldung kommt erst wenn ich die Anfrage auf der aktuellen Seite 2 abschicken möchte, das Dokument aber nicht vollständig ausgefüllt wurde. Um von Seite 2 nämlich erfolgreich auf Seite 3 zu gelangen müssen Pflichtfelder wie Name, Nachname, E-Mail ausgefüllt werden. Vergisst man hier eine notwendige Eingabe und nimmt dann den Browser-Zurück-Button erscheint die Meldung "Dieses Dokument ist nicht mehr verfügbar".

Die Fehlermeldung wird hier über einen array() geprüft und angelegt. Sprich bei einer Bedingung wie !$_POST['vorname'] kommt eine Fehlermeldung in den array.

[src=php]
if (!$_POST['vorname']) {
$aErrors[] = "Sie müssen einen Vornamen angeben!";
}
[/src]

Denke das es mit diesem array zusammenhängt.

[src=php]if (!empty($aErrors)) {
if (!empty($aErrors)) {
echo showError($aErrors);
} else {
weiter zu Seite 3
}[/src]

Jemand dazu eine Idee?

 

[Shodan]

Leider gibt es dafür keine wirklich gute Praxis, oder zumindest ist mir keine bekannt. Auf POST mit 200 zu antworten ist in Sachen "Zurück Button" ein Point of no return. Auf Tricks mit dem Cache würde ich da nicht setzen, dafür sind die Implementationen der verschiedenen Browser schlicht zu unterschiedlich.
Wenn du "Zurück" wirklich voll zur Verfügung haben willst, kommst an einem radikalen Post-Redirect-Get (der normale Anwendungsfall wäre eine valide Eingabe, um Mehrfachabsendung und hässliche Browsermeldungen zu vermeiden) nicht vorbei. Dabei verarbeitest du die Daten nach einem Post (bzw lagerst sie in einer Session), antwortest immer mit 303 und lässt den Client eine Get Anfrage für die Antwortseite senden. Das ist technologisch ziemlich hässlich, da es Standartfunktionalität nachbaut (befüllen einer falsch ausgefüllten Eingabemaske mit den abgesendeten Daten) und andauernd umleitet. Dafür hat es aber eine hohe Usability.

Eine mögliche Alternative wäre auf Seite 2 die eine Vorabprüfung mit Javascript zu machen. Das Problem tritt ja auf da der Prozess so aussieht:
Seite 1 --Post--> Seite 2(a) --Post--> Seite 2(b)
von b kann nicht auf a zurück gesprungen werden, da diese mittels Post erstellt wurde. Validierst du ersteinmal mit Javascript findet der zweite Post nicht statt (Bonuspunkt: User die fünf mal ihren Vornamen falsch eingeben springen mit zurück nicht fünf mal auf das Formular sondern gleich zu Seite 1). Der Server muss die Eingabe natürlich immer noch prüfen, aber 95+% deiner User werden valide Daten posten.

Kombiniert käme dann das in Frage:
Seite 1 --PRG--> Seite 2(a) --JS--> Seite 2(b) --PRG--> Seite 3
Das spart dir das "auf sich selbst umleiten", stellt die zurück Funktionalität zur Verfügung, und ist technologisch nicht so grausam. In ein paar Fällen (kein JS, clientseitige Valididerung nicht möglich, zB wegen einem Datenbankzugriff) zieht das allerdings nicht.

Eine bessere Lösung fällt mir dazu nicht ein, vielleicht zieht ja Kugelfisch noch was aus dem Hut

 

[godlike]

Puh, das ist hart. Ich denke nicht das hier wegen dieser "Kleinigkeit" so dermaßen loslegen möchte. Dann müssen die paar Leute, die meinen nach einem abgeschickten Formular und aufgeploppter Fehlermeldung mittlels Browser-Zurück-Button zu hantieren, eben die Fehlermeldung ertragen. Immerhin taucht diese im Internet ja ab und an auf, dürfte also einigermaßen geläufig sein - das Internet gibts jetzt ja schon ein paar Tage

Die Prüfung will ich auf jeden Fall auch ohne Javascript ermöglichen da sonst mit deaktiviertem JS kein Bestellvorgang möglich wäre bzw. keine Fehlermeldung den Benutzer auf seine Fehler aufmerksam machen würde. Das halte ich irgendwie für kontraproduktiv.

Trotzdem Danke für deine Idee