tintifaxine: Bei "Zurück" soll die Seite neu geladen werden

Hallo,

ich habe folgendes Problem: auf meiner Seite ist ein User eingeloggt, ein Cookie ist gesetzt. Er loggt sich aus, das Cookie wird gelöscht, er kommt auf eine Seite, wo ich die Abmeldung bestätige.

Funktioniert alles pipifein.

Problem: drückt er auf "Zurück" kommt die vorherige Seite auf der noch immer steht, dass er angemeldet ist. Obwohl kein Cookie mehr da ist etc.

Ich habe schon folgendes im Head versucht, was leider nicht funktioniert:

  
<meta http-equiv=Expires content="Mon, 26 Jul 1997 05:00:00 GMT">  
<meta http-equiv=Cache-Control content="no-store, no-cache, must-revalidate">  
<meta http-equiv=Cache-Control content="post-check=0, pre-check=0", false">  
<meta http-equiv=Pragma content="no-cache">  
<meta http-equiv="Expires" content="-1" />  

Wer kann bitte helfen?

Herzlichen Dank im Voraus!

  1. Hi,

    Problem: drückt er auf "Zurück" kommt die vorherige Seite auf der noch immer steht, dass er angemeldet ist. Obwohl kein Cookie mehr da ist etc.

    Dein Wunsch ist also zu erreichen, dass Dokumente in keinem Fall in veralteter Version aus dem Cache angezeigt werden sollen, sondern immer neu geladen werden sollen? Oder nur überprüft, ob sich ihr Status geändert hat? (Letzteres müsstest du zum Teil im Script selber implementieren, Stichworte HTTP-Header If-Modified-Since/Last-Modified/Status 304 Not Modified.)

    Ich habe schon folgendes im Head versucht, was leider nicht funktioniert:

    <meta http-equiv=Expires content="Mon, 26 Jul 1997 05:00:00 GMT">
    <meta http-equiv=Cache-Control content="no-store, no-cache, must-revalidate">
    <meta http-equiv=Cache-Control content="post-check=0, pre-check=0", false">
    <meta http-equiv=Pragma content="no-cache">
    <meta http-equiv="Expires" content="-1" />

      
    Alle diese Angaben sind im HTML untergebracht relativ kraftlos, wenn in den tatsächlichen HTTP Response-Headern, mit denen das Dokument bzw. die Ressource ausgeliefert wird, andere Angaben gemacht werden (sollten).  
      
    
    > Wer kann bitte helfen?  
      
    Dazu müssten wir erst mal wissen, mit welcher serverseitigen Technik deine Seite arbeitet?  
      
    Wenn PHP-Sessions im Einsatz sind, lassen sich über die Konfiguration bspw. ein paar Angaben machen, die sich auf das Caching auswirken, siehe <http://www.php.net/manual/en/session.configuration.php>, insb. session.cache\_limiter und session.cache\_expire.  
      
    Ggf. könnte es sich noch empfehlen, über die Funktion [header](http://www.php.net/manual/en/function.header.php) eigene Caching-Angaben über entsprechende HTTP-Header zu machen, falls man das Verhalten genauer spezifizieren möchte. Dazu wäre dann aber eine Einarbeitung in die HTTP-Grundlagen erforderlich.  
      
    MfG ChrisB  
      
    
    -- 
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    
    1. Problem: drückt er auf "Zurück" kommt die vorherige Seite auf der noch immer steht, dass er angemeldet ist. Obwohl kein Cookie mehr da ist etc.

      Dein Wunsch ist also zu erreichen, dass Dokumente in keinem Fall in veralteter Version aus dem Cache angezeigt werden sollen, sondern immer neu geladen werden sollen? Oder nur überprüft, ob sich ihr Status geändert hat? (Letzteres müsstest du zum Teil im Script selber implementieren, Stichworte HTTP-Header If-Modified-Since/Last-Modified/Status 304 Not Modified.)

      Opera ist das z.B. herzlich egal - bei vor und zurück werden keine HTTP-Requests abgesetzt, die Seiten werden 1:1 aus dem Cache sofort und ohne Umschweife angezeigt.

      1. Hallo,

        Opera ist das z.B. herzlich egal - bei vor und zurück werden keine HTTP-Requests abgesetzt, die Seiten werden 1:1 aus dem Cache sofort und ohne Umschweife angezeigt.

        stimmt, das ist eine der wenigen Eigenheiten, die mich am Opera sehr stören: Nach dem "Back" muss man oft erst noch explizit ein Reload auslösen. Die Einstellung "Check if cached page is updated on server" scheint er zu ignorieren, sie kann ruhig auf "Always" stehen. Hilft nicht.

        Ciao,
         Martin

        --
        Die Zeit, die man zur Fertigstellung eines Projekts wirklich braucht, ist immer mindestens doppelt so lang wie geplant.
        Wurde dieser Umstand bei der Planung bereits berücksichtigt, gilt das Prinzip der Rekursion.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. Opera ist das z.B. herzlich egal - bei vor und zurück werden keine HTTP-Requests abgesetzt, die Seiten werden 1:1 aus dem Cache sofort und ohne Umschweife angezeigt.

          stimmt, das ist eine der wenigen Eigenheiten, die mich am Opera sehr stören

          Im Gegenteil, ich finde das verhalten sehr genial und möchte es nicht missen.

          1. Moin!

            Opera ist das z.B. herzlich egal - bei vor und zurück werden keine HTTP-Requests abgesetzt, die Seiten werden 1:1 aus dem Cache sofort und ohne Umschweife angezeigt.

            stimmt, das ist eine der wenigen Eigenheiten, die mich am Opera sehr stören

            Im Gegenteil, ich finde das verhalten sehr genial und möchte es nicht missen.

            Insbesondere ist das Verhalten der History sogar in den RFCs genau so definiert worden. Browser, die das anders machen, verhalten sich also nicht so, wie dort beschrieben.

            - Sven Rautenberg

            1. Insbesondere ist das Verhalten der History sogar in den RFCs genau so definiert worden. Browser, die das anders machen, verhalten sich also nicht so, wie dort beschrieben.

              Hast den entsprechenden RFC zur Hand?

              1. Moin!

                Insbesondere ist das Verhalten der History sogar in den RFCs genau so definiert worden. Browser, die das anders machen, verhalten sich also nicht so, wie dort beschrieben.

                Hast den entsprechenden RFC zur Hand?

                RFC 2616, Sektion 13.13:
                "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."
                http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

                Opera brilliert in dieser Disziplin, indem auch teilausgefüllte Formulare meistens durch History wieder gerettet werden können, sofern man aus Versehen eine andere Seite aufgerufen hat anstatt das Formular abzusenden.

                - Sven Rautenberg

                1. Opera brilliert in dieser Disziplin, indem auch teilausgefüllte Formulare meistens durch History wieder gerettet werden können, sofern man aus Versehen eine andere Seite aufgerufen hat anstatt das Formular abzusenden.

                  Sofern der Browser nicht stirbt, ja :)

                2. Hi,

                  RFC 2616, Sektion 13.13:
                  "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."

                  Opera brilliert in dieser Disziplin, indem auch teilausgefüllte Formulare meistens durch History wieder gerettet werden können, sofern man aus Versehen eine andere Seite aufgerufen hat anstatt das Formular abzusenden.

                  Was aber der oben zitierten Stelle der RFC widerspricht - denn die Formulare wurden ja erst teilausgefüllt, nachdem die Resource retrieved wurde ...

                  (daß das userfreundlich sein mag, ist ja nochmal was anderes)

                  cu,
                  Andreas

                  --
                  Warum nennt sich Andreas hier MudGuard?
                  O o ostern ...
                  Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.