http - webseiten - website parsen php




Wie kontrolliert man das Zwischenspeichern von Webseiten in allen Browsern? (18)

Einführung

Der richtige Mindestsatz von Headern, der für alle genannten Clients (und Proxies) gilt:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Das Cache-Control der HTTP 1.1-Spezifikation für Clients und Proxys (und wird von einigen Clients implizit neben Expires ). Das Pragma der HTTP 1.0-Spezifikation für prähistorische Clients. Das Expires den HTTP Expires und 1.1-Spezifikationen für Clients und Proxys. In HTTP 1.1 hat das Cache-Control Vorrang vor Expires , also nur für HTTP 1.0-Proxies.

Wenn Sie IE6 und sein unterbrochenes Caching beim Bereitstellen von Seiten über HTTPS mit nur no-store nicht interessieren, können Sie Cache-Control: no-cache weglassen.

Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

Wenn Sie IE6- oder HTTP 1.0-Clients nicht interessieren (HTTP 1.1 wurde 1997 eingeführt), können Sie Pragma auslassen.

Cache-Control: no-store, must-revalidate
Expires: 0

Wenn Sie sich auch nicht für HTTP 1.0-Proxies Expires , können Sie Expires auslassen.

Cache-Control: no-store, must-revalidate

Auf der anderen Seite, wenn der Server automatisch einen gültigen Date Header enthält, könnten Sie theoretisch auch Cache-Control weglassen und sich nur auf Expires .

Date: Wed, 24 Aug 2016 18:32:02 GMT
Expires: 0

Dies kann jedoch fehlschlagen, wenn z. B. der Endbenutzer das Betriebssystemdatum manipuliert und die Client-Software darauf vertraut.

Andere Cache-Control Parameter wie max-age sind irrelevant, wenn die oben genannten Cache-Control Parameter spezifiziert sind. Der Header " Last-Modified der in den meisten anderen Antworten enthalten ist, ist nur dann interessant, wenn Sie die Anforderung tatsächlich zwischenspeichern möchten , sodass Sie sie nicht angeben müssen.

Wie man es einstellt?

Mit PHP:

header("Cache-Control: no-cache, no-store, must-revalidate"); // HTTP 1.1.
header("Pragma: no-cache"); // HTTP 1.0.
header("Expires: 0"); // Proxies.

Verwenden Sie Java Servlet oder Node.js:

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setHeader("Expires", "0"); // Proxies.

Verwenden von ASP.NET-MVC

Response.Cache.SetCacheability(HttpCacheability.NoCache);  // HTTP 1.1.
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Verwenden von ASP.NET:

Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Verwenden von ASP:

Response.addHeader "Cache-Control", "no-cache, no-store, must-revalidate" ' HTTP 1.1.
Response.addHeader "Pragma", "no-cache" ' HTTP 1.0.
Response.addHeader "Expires", "0" ' Proxies.

Verwenden von Ruby on Rails oder Python / Flask:

response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response.headers["Pragma"] = "no-cache" # HTTP 1.0.
response.headers["Expires"] = "0" # Proxies.

Verwenden von Python / Django:

response["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response["Pragma"] = "no-cache" # HTTP 1.0.
response["Expires"] = "0" # Proxies.

Verwenden von Python / Pyramid:

request.response.headerlist.extend(
    (
        ('Cache-Control', 'no-cache, no-store, must-revalidate'),
        ('Pragma', 'no-cache'),
        ('Expires', '0')
    )
)

Google Go verwenden:

responseWriter.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") // HTTP 1.1.
responseWriter.Header().Set("Pragma", "no-cache") // HTTP 1.0.
responseWriter.Header().Set("Expires", "0") // Proxies.

Apache .htaccess Datei verwenden:

<IfModule mod_headers.c>
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires 0
</IfModule>

Verwenden von HTML4:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

HTML-Metatags und HTTP-Antwortheader

Wenn eine HTML-Seite über eine HTTP-Verbindung bereitgestellt wird und ein Header sowohl in den HTTP-Antwortheadern als auch in den HTML <meta http-equiv> Tags <meta http-equiv> , erhält der im HTTP <meta http-equiv> angegebene Vorrang über das HTML-Meta-Tag. Das HTML-Metatag wird nur verwendet, wenn die Seite vom Dateisystem des lokalen Datenträgers aus über eine file:// URL angezeigt wird. Siehe auch W3 HTML-Spezifikation Kapitel 5.2.2 . Seien Sie vorsichtig damit, wenn Sie sie nicht programmgesteuert angeben, da der Webserver nämlich einige Standardwerte enthalten kann.

Im Allgemeinen sollten Sie die HTML-Metatags einfach nicht angeben, um Verwirrung bei Startern zu vermeiden, und sich auf harte HTTP-Antwortheader verlassen. Darüber hinaus sind speziell diese <meta http-equiv> -Tags in HTML5 ungültig . Nur die in der HTML5-Spezifikation aufgeführten http-equiv Werte sind zulässig.

Überprüfen der tatsächlichen HTTP-Antwortheader

Um das eine und das andere zu überprüfen, können Sie sie im HTTP-Verkehrsmonitor des Webbrowser-Entwickler-Toolsets sehen / debuggen. Sie können dorthin gelangen, indem Sie F12 in Chrome / Firefox23 + / IE9 + drücken, dann die Registerkarte "Netzwerk" oder "Net" öffnen und dann auf die gewünschte HTTP-Anfrage klicken, um alle Details zur HTTP-Anfrage und -Antwort anzuzeigen. Der folgende Screenshot stammt aus Chrome:

Ich möchte diese Header auch auf Dateidownloads setzen

Diese Frage und Antwort richtet sich zunächst auf "Webseiten" (HTML-Seiten), nicht auf "Datei-Downloads" (PDF, Zip, Excel, etc.). Sie sollten sie lieber zwischenspeichern und eine Dateiversions-ID irgendwo im URI-Pfad oder Querystring verwenden, um ein Redownload für eine geänderte Datei zu erzwingen. Wenn Sie diese No-Cache-Header trotzdem auf Dateidownloads anwenden, sollten Sie den IE7 / 8-Fehler beachten, wenn Sie einen Dateidownload über HTTPS statt HTTP bereitstellen. Für Details, siehe IE kann foo.jsf nicht herunterladen. IE konnte diese Internetseite nicht öffnen. Die angeforderte Site ist entweder nicht verfügbar oder kann nicht gefunden werden .

Unsere Untersuchungen haben uns gezeigt, dass nicht alle Browser die http-Cache-Anweisungen einheitlich einhalten.

Aus Sicherheitsgründen möchten wir bestimmte Seiten in unserer Anwendung niemals im Webbrowser zwischenspeichern. Dies muss für mindestens die folgenden Browser funktionieren:

  • Internet Explorer 6+
  • Firefox 1.5+
  • Safari 3+
  • Oper 9+
  • Chrom

Unsere Anforderung kam von einem Sicherheitstest. Nachdem Sie sich von unserer Website ausgeloggt haben, können Sie die Zurück-Taste drücken und zwischengespeicherte Seiten anzeigen.


(hey, alle: bitte kopiere nicht einfach alle Header die du finden kannst)

Der Back-Button-Verlauf ist zunächst kein Cache :

Das Frischemodell (Abschnitt 4.2) trifft nicht notwendigerweise auf historische Mechanismen zu. Das heißt, ein Historienmechanismus kann eine vorherige Repräsentation anzeigen, selbst wenn sie abgelaufen ist.

In der alten HTTP-Spezifikation war der Wortlaut sogar noch stärker und wies die Browser explizit an, die Cache-Anweisungen für den Back-Button-Verlauf zu ignorieren.

Zurück soll in die Zeit zurückgehen (zu der Zeit als der Benutzer angemeldet war). Es navigiert nicht zu einer zuvor geöffneten URL.

In der Praxis kann der Cache jedoch den Back-Button unter bestimmten Umständen beeinflussen:

  • Die Seite muss über HTTPS geliefert werden, sonst wird dieses Cache-Busting nicht zuverlässig sein. Außerdem, wenn Sie nicht HTTPS verwenden, ist Ihre Seite anfällig für Login-Diebstahl auf viele andere Arten.
  • Sie müssen Cache-Control: no-store, must-revalidate senden Cache-Control: no-store, must-revalidate (einige Browser beobachten no-store und einige beobachten must-revalidate )

Du brauchst nie eines von:

  • <meta> mit Cache-Headern - es funktioniert überhaupt nicht. Total nutzlos.
  • Nachprüfung / Vorabprüfung - Dies ist eine IE-Direktive, die nur für zwischengespeicherte Ressourcen gilt.
  • Senden Sie den gleichen Header zweimal oder in dutzend Teilen. Einige PHP-Snippets da draußen ersetzen vorherige Header, was dazu führt, dass nur der letzte gesendet wird.

Wenn Sie möchten, können Sie hinzufügen:

  • no-cache oder max-age=0 , wodurch die Ressource (URL) "veraltet" wird und Browser mit dem Server abfragen müssen, ob es eine neuere Version gibt ( no-store impliziert dies sogar noch stärker).
  • Expires mit einem Datum in der Vergangenheit für HTTP / 1.0-Clients ab (obwohl echte HTTP / 1.0-Clients Expires nicht existieren).

Bonus: Der neue HTTP-Caching-RFC .


Das Festlegen des modifizierten HTTP-Headers auf ein Datum im Jahr 1995 führt normalerweise zum Erfolg.

Hier ist ein Beispiel:

Expires: Wed, 15 Nov 1995 04:58:08 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Cache-Control: no-cache, must-revalidate

Der RFC für HTTP 1.1 besagt, dass die richtige Methode darin besteht, einen HTTP-Header hinzuzufügen für:

Cache-Kontrolle: Kein Cache

Ältere Browser ignorieren dies möglicherweise, wenn sie nicht ordnungsgemäß mit HTTP 1.1 kompatibel sind. Für diese können Sie die Überschrift versuchen:

Pragma: Kein Cache

Dies soll auch für HTTP 1.1 Browser funktionieren.


Die Header in der Antwort von BalusC hindert Safari 5 (und möglicherweise auch ältere Versionen) nicht daran, Inhalte aus dem Browser-Cache anzuzeigen, wenn die Zurück-Schaltfläche des Browsers verwendet wird. Eine Möglichkeit, dies zu verhindern, besteht darin, dem body-Tag ein leeres onunload-Event-Handler-Attribut hinzuzufügen:

<body onunload=""> 

Dieser Hack unterbricht anscheinend den Back-Forward-Cache in Safari: Gibt es ein browserübergreifendes Onload-Ereignis beim Klicken auf die Zurück-Schaltfläche?



Diese Richtlinien mindern kein Sicherheitsrisiko. Sie sind eigentlich dazu gedacht, UA's zu zwingen, flüchtige Informationen aufzufrischen und nicht zu verhindern, dass UAs Informationen behalten. Siehe diese ähnliche Frage . Zumindest gibt es keine Garantie, dass Router, Proxies usw. die Caching-Anweisungen nicht ignorieren.

Positiv zu vermerken ist, dass Richtlinien in Bezug auf physischen Zugriff auf Computer, Softwareinstallation und Ähnliches Ihnen in Bezug auf die Sicherheit Meilen vorausgehen werden. Wenn die Verbraucher dieser Informationen Mitglieder der Öffentlichkeit sind, können Sie ihnen nur helfen, zu verstehen, dass, sobald die Informationen auf ihre Maschine treffen, diese Maschine in ihrer Verantwortung liegt, nicht Ihre.


Erstellen Sie für ASP.NET Core eine einfache Middleware-Klasse:

public class NoCacheMiddleware
{
    private readonly RequestDelegate m_next;

    public NoCacheMiddleware( RequestDelegate next )
    {
        m_next = next;
    }

    public async Task Invoke( HttpContext httpContext )
    {
        httpContext.Response.OnStarting( ( state ) =>
        {
            // ref: http://.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers
            httpContext.Response.Headers.Append( "Cache-Control", "no-cache, no-store, must-revalidate" );
            httpContext.Response.Headers.Append( "Pragma", "no-cache" );
            httpContext.Response.Headers.Append( "Expires", "0" );
            return Task.FromResult( 0 );
        }, null );

        await m_next.Invoke( httpContext );
    }
}

dann registrieren Sie es mit Startup.cs

app.UseMiddleware<NoCacheMiddleware>();

Stellen Sie sicher, dass Sie dies nachher hinzufügen

app.UseStaticFiles();

Ich fand die web.config-Route nützlich (versuchte, sie zur Antwort hinzuzufügen, scheint aber nicht akzeptiert worden zu sein, um hier zu posten)

<configuration>
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Cache-Control" value="no-cache, no-store, must-revalidate" />
            <!-- HTTP 1.1. -->
            <add name="Pragma" value="no-cache" />
            <!-- HTTP 1.0. -->
            <add name="Expires" value="0" />
            <!-- Proxies. -->
        </customHeaders>
    </httpProtocol>
</system.webServer>

Und hier ist der Weg von express / node.js:

app.use(function(req, res, next) {
    res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');
    res.setHeader('Pragma', 'no-cache');
    res.setHeader('Expires', '0');
    next();
});

Ich fand, dass alle Antworten auf dieser Seite immer noch Probleme hatten. Insbesondere fiel mir auf, dass keiner von ihnen IE8 daran hindern würde, eine zwischengespeicherte Version der Seite zu verwenden, wenn Sie darauf durch Drücken der Zurück-Taste zugegriffen hatten.

Nach vielen Recherchen und Tests stellte ich fest, dass die einzigen zwei Header, die ich wirklich brauchte, waren:

Cache-Control: Nicht speichern
Variieren: *

Eine Erläuterung des Vary-Headers finden Sie unter http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6

Bei IE6-8, FF1.5-3.5, Chrome 2-3, Safari 4 und Opera 9-10 bewirkten diese Header, dass die Seite vom Server angefordert wurde, wenn Sie auf einen Link zu der Seite klicken oder die URL eingeben direkt in der Adressleiste. Dies deckt ungefähr 99% aller Browser ab, die seit Januar 2010 verwendet werden.

Bei IE6 und Opera 9-10 führte das Drücken der Zurück-Taste immer noch dazu, dass die zwischengespeicherte Version geladen wurde. In allen anderen Browsern, die ich getestet habe, haben sie eine neue Version vom Server heruntergeladen. Bisher habe ich keine Header gefunden, die dazu führen, dass diese Browser keine zwischengespeicherten Versionen von Seiten zurückgeben, wenn Sie die Zurück-Taste drücken.

Update: Nachdem ich diese Antwort geschrieben hatte, erkannte ich, dass unser Webserver sich selbst als HTTP 1.0 Server identifiziert. Die Header, die ich aufgelistet habe, sind die richtigen, damit Antworten von einem HTTP 1.0-Server nicht von Browsern zwischengespeichert werden. Sehen Sie sich für einen HTTP 1.1-Server die answer BalusC an.


Nach ein wenig Nachforschung kamen wir auf die folgende Liste von Kopfzeilen, die die meisten Browser zu umfassen schienen:

In ASP.NET haben wir diese mithilfe des folgenden Snippets hinzugefügt:

Response.ClearHeaders(); 
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.0 

Gefunden von: http://forums.asp.net/t/1013531.aspx


Wenn Sie Download-Probleme mit IE6-IE8 über SSL und Cache: no-cache header (und ähnliche Werte) mit MS Office-Dateien haben, können Sie cache: private, no-store Header und return file on POST request verwenden. Es klappt.


in meinem Fall behebe ich das Problem in Chrom mit diesem

<form id="form1" runat="server" autocomplete="off">

Hier muss ich den Inhalt der vorherigen Formulardaten löschen, wenn die Benutzer aus Sicherheitsgründen auf die Schaltfläche klicken


Also, just for good measure, make sure you reset the ExpiresDefault in your .htaccess file if you're using that to enable caching.

ExpiresDefault "access plus 0 seconds"

Afterwards, you can use ExpiresByType to set specific values for the files you want to cache:

ExpiresByType image/x-icon "access plus 3 month"

This may also come in handy if your dynamic files eg php, etc. are being cached by the browser, and you can't figure out why. Check ExpiresDefault .


I just want to point out that if someone wants to prevent caching ONLY dynamic content, adding those additional headers should be made programmatically.

I edited configuration file of my project to append no-cache headers, but that also disabled caching static content, which isn't usually desirable. Modifying response headers in code assures that images and style files will be cached.

This is quite obvious, yet still worth mentioning.

And another caution. Be careful using ClearHeaders method from HttpResponse class. It may give you some bruises if you use it recklessly. Like it gave me.

After redirecting on ActionFilterAttribute event the consequences of clearing all headers are losing all session data and data in TempData storage. It's safer to redirect from an Action or don't clear headers when redirection is taking place.

On second thought I discourage all to use ClearHeaders method. It's better to remove headers separately. And to set Cache-Control header properly I'm using this code:

filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.AppendCacheExtension("no-store, must-revalidate");

In addition to the headers consider serving your page via https . Many browsers will not cache https by default.


To complete BalusC -> answer If you are using perl you can use CGI to add HTTP headers.

Using Perl:

Use CGI;    
sub set_new_query() {
        binmode STDOUT, ":utf8";
        die if defined $query;
        $query = CGI->new();
        print $query->header(
                        -expires       => 'Sat, 26 Jul 1997 05:00:00 GMT',
                        -Pragma        => 'no-cache',
                        -Cache_Control => join(', ', qw(
                                            private
                                            no-cache
                                            no-store
                                            must-revalidate
                                            max-age=0
                                            pre-check=0
                                            post-check=0 
                                           ))
        );
    }

Using apache httpd.conf

<FilesMatch "\.(html|htm|js|css|pl)$">
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>

Note: When I tried to use the html META, browsers ignored them and cached the page.


//In .net MVC
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public ActionResult FareListInfo(long id)
{
}

// In .net webform
<%@ OutputCache NoStore="true" Duration="0" VaryByParam="*" %>






http-headers