Comment puis-je arrêter de l'Opéra de mise en cache d'une page?

J'essaie d'obtenir de l'Opéra de re-demande une page à chaque fois au lieu de simplement servir à partir de la mémoire cache. Je suis d'envoyer le 'Cache-control: no-cache' et 'Pragma: no-cache' en-têtes de réponse, mais il me semble que si l'Opéra est simplement ignorer ces en-têtes. Il fonctionne très bien dans d'autres navigateurs (Chrome, IE, Firefox.

Comment puis-je arrêter l'Opéra de mise en cache de pages? Ce que je veux être en mesure de faire de l'Opéra de re-demander une page lorsque l'utilisateur clique sur le bouton Retour du navigateur.

OriginalL'auteur Nishkar | 2010-05-19

  1. 7

    En tant qu'utilisateur, j'ai absolument horreur de pages qui ralentissent mon historique de navigation en forçant re-charges lorsque j'utilise le bouton de retour. (Si le navigateur que vous utilisez sur une base quotidienne payé l'attention sur les différentes consignes de mise en cache et les laisser affecter l'histoire de la navigation, la façon dont vous le souhaitez tant que développeur, vous auriez probablement remarqué que certains sites ralentissement de soi...)

    Si vous avez une très forte cas d'utilisation pour ce faire, je dirais que votre architecture peut être "mauvais" dans un certain sens - par exemple, si vous êtes à la commutation entre les différents "points de vue" de la mise à jour constante des données et donc à appliquer les re-charger lorsque les utilisateurs remontent peut-être à l'aide de Ajaxy techniques pour le chargement à l'évolution constante des données dans la page actuelle serait mieux?

    De l'opéra de mise en œuvre est dans la "mise en cache" est vu comme conceptuellement différent de "historique de navigation", le premier est plus sur le stockage des choses sur le disque et entre les sessions, le dernier est le retour à une temporairement masqué page que vous venez de visiter, dans l'état vous l'avez laissé.

    Toutefois, si vous avez vraiment, vraiment besoin de cela il y a une faille dans cette politique qui permet le comportement que vous voulez. L'envoi de "Cache-control: must-revalidate" force de l'Opéra de re-charger chaque page sur la navigation, mais seulement si vous désirez envoyer la page en https. (Ceci est une fonctionnalité demandée par et prévu pour paranoid banques, il ralentit beaucoup trop normale de sites sur http).

    "C'est une fonctionnalité demandée par et prévu pour paranoid banques, il ralentit beaucoup trop normale de sites sur http" vous dites que les navigateurs ne devrait pas vraiment être utilisé pour les applications qui peuvent avoir des données sensibles? 🙂
    Si les données sont vraiment sensibles, les sites doivent utiliser le protocole https. 🙂 Il y a un trou dans le web les spécifications ici, comme il n'y a pas de notion de "sessions" partagé entre le serveur et le navigateur. Si le serveur est capable de dire au navigateur "il suffit à l'utilisateur connecté/a expiré et nous avons fermé sa session, veuillez interdire à l'aide du bouton retour pour voir l'histoire depuis la session a été lancée", nous serions en mesure de trouver un meilleur équilibre entre la facilité d'utilisation et de sécurité.
    Je suis d'accord avec les deux points: (i) il y a un trou dans le site web de la spécification en ce qui concerne une "session partagée de l'état" & (ii) https doit être utilisé pour vraiment sensible. Mais, "en vérité, les données sensibles" est une indication que la sécurité des données n'est pas numérique, mais un analogue de la mesure. D'autres navigateurs prennent en charge ce problème en permettant pas de cache & must-revalidate de travailler indépendamment, ce qui permet davantage de possibilités dans la gestion de la sécurité/confidentialité. Opera ne supporte pas cette - de bonne ou de mauvaise, je ne suis pas concerné. J'ai besoin d'une solution pour contourner cette incohérence. U travail à l'Opéra, ce que u peut suggérer? (c'est à dire de script, en-tête, etc.) Thks
    Il n'y a aucun moyen que je sais à propos de manière fiable la force de revalidation si vous n'êtes pas sur https. Nous travaillons sur des propositions pour résoudre ce problème, par exemple: ietf.org/id/draft-pettersen-cache-context-05.txt Une mise en œuvre réelle est probablement un peu de temps loin - dans l'attente de la poursuite de la discussion de la proposition.

    OriginalL'auteur hallvors

  2. 2

    Il semble que votre problème est lié à cette réponse. Après le test de votre en-tête et l'a suggéré en-têtes, je n'ai pu reproduire le comportement attendu dans Internet Explorer.

    J'ai à plusieurs reprises reproduire ce problème sur l'Opéra. Il semble être le seul navigateur incompatible. J'ai lu sur leur strict, l'approche fondée sur les principes de la manipulation de la mise en cache. Mais c'est pratiquement juste en le regardant comme un trou de sécurité sans faire supplémentaire de la jambe de travail. J'aimerais vraiment explicite d'une solution qui peut être mis en œuvre pour nishkarr de questions. L'en-tête de contrôle de cache reponse en-têtes de ne pas travailler dans l'opéra que dans les autres navigateurs. Qu'est-ce que le travail?

    OriginalL'auteur Quai

  3. 2

    SIMPLE SERVERSIDE DE CONTRÔLE DE CACHE SANS LES EN-TÊTES OU FRONTEND SCRIPTS

    Zéro De La Dépendance, La Langue Universelle De L'Édition

    Vous pouvez forcer la mise en cache de partout dans le monde sans l'aide d'un en-tête en ajoutant un md5 ou sha1 de la somme de contrôle de votre nom de fichier.

    Que la façon dont il se cache si c'est une correspondance exacte, et autrement traiter comme une nouvelle ressource.

    • Fonctionne dans tous les navigateurs
    • Valide aussi stricte HTML5 (à l'origine n'a pas, mais ce qui a été mis à jour. Non testé pour le XHTML, mais probablement pas valide pour que)
    • Ne nécessite pas des en-têtes supplémentaires
    • Garde frontend préoccupations et backend préoccupations bien découplé.
    • Ne nécessite pas de côté client des contrôles d'intégrité ou de la validation de la source.
    • Tout ce qui peut imprimer html peut le faire de façon systématique, y compris le contenu statique
    • Si pas statique, facile à étendre l'autonomie de contrôle pour les utilisateurs finaux (avec authentification, si désiré) qui permet pour la simple page d'indicateurs pour déterminer minifiés, embellie, ou de débogage source retourné.
    • Entièrement encapsule client de contrôle de cache dans le mécanisme de diffusion de contenu, ce qui rend les choses super simple à entretenir.

    • Que d'un côté perk, introduit de version mise en cache côté client automatiquement par le report de l'sommes le navigateur a mis en cache, ce qui peut être utile si vous avez d'autres versions et nécessité de l'unité de tester une version de package de déterminer minimum stable de dépendance versions ou quelque chose.

    • Vous n'avez pas jamais avez à jouer avec votre navigateur pour obtenir la mise en cache de ne pas interférer avec le processus de développement de nouveau.

    • Cette approche peut également être utilisé pour de version images, vidéo, audio, pdf, etc. Assez bien toute ressource qui est servi sous forme de données statiques fonctionnera de la même manière, la mise en cache sur la première demande pour le contenu, et persistent automatiquement, sans autre considération que si le fichier ne change pas.

    C'est la RFC balises valides. Avis le script et le lien des balises d'obtenir de la chaîne:

    ?checksum=ba411cafee2f0f702572369da0b765e2

    <!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">

  <title>Client Cache Control Example</title>
  <meta name="description" content="You're only going to cache this when the content changes, and always when the content changes.">
  <meta name="author" content="https://stackoverflow.com/users/1288121/mopsyd">

  <!-- Example Stylesheet -->
  <link  href="css/styles.css?checksum=ba411cafee2f0f702572369da0b765e2">

  <!-- Example Script -->
  <script src="js/scripts.js?checksum=ba411cafee2f0f702572369da0b765e2"></script>
</head>
<body>
</body>
</html>

    OBTENIR la chaîne de ?checksum=ba411cafee2f0f702572369da0b765e2 fait référence à un MD5 ou SHA1 hash de la taille de la ressource. Il peut être obtenu par le biais d'une ligne de commande, la construction du langage, ou le hachage de la valeur de la Content-Length: en-tête. Vous ensuite construire votre href ou src attribut, en ajoutant comme une chaîne de caractères pour le nom de fichier.

    Ce navigateur va interpréter comme distinctes, et cache séparément.

    Le serveur ignorera le paramètre GET si c'est une ressource statique, mais si c'est servi de façon dynamique, alors le paramètre GET sera disponible à la langue d'interprétation.

    Cela signifie que chaque fois que les modifications de hachage dans les liens, le navigateur met en cache cette version spécifique indépendamment un temps, puis le conserver jusqu'à l'éternité, ou Expires:, selon la première éventualité.

    Depuis la somme de contrôle est un reflet direct de la taille du fichier, vous pouvez définir Expires: à jamais et il ne fait pas beaucoup de différence. Vous pourrez tout de même voir vos modifications immédiatement dès que la modification de ce fichier, même d'un seul octet.

    • Générer votre code css ou js source avec les utilitaires que vous le feriez normalement.

    • Exécuter un md5 ou sha1 de la somme de contrôle sur la taille du fichier au moment de l'exécution si vous vous servez de façon dynamique, et à compile-time si vous générez du contenu statique (comme ApiGen docs, par exemple).

    • Desservir le fichier normal avec le hachage comme une chaîne ajoutée au nom du fichier (par exemple: styles.css devient styles.css?checksum=ba411cafee2f0f702572369da0b765e2)

    • Tout changement dans le fichier forces une remettez en cache, ce qui signifie que vous voir la vraie valeur se reflète immédiatement.

    • Facultatif, mais rad: Un autre avantage de cette approche est que vous pouvez facilement mettre en place un dev OBTENIR drapeau, qui fera TOUS frontend source résoudre à embellie dev source avec tout de votre propre fonctionnalité de débogage activé, ou l'utiliser pour interpréter le versioning des drapeaux. Vous pouvez faire un redondante assurez-vous que le drapeau est transmis uniquement à partir d'une élaboration de l'adresse IP, l'authentification par proxy, etc. par le serveur et le contraire n'est pas honoré si vous avez besoin d'un lieu sûr. J'ai l'habitude de diviser mon frontend source chaque fois que possible similaire à ceci:

      • C'est ce qu'il est en train de faire sur le live en ce moment (minimisé la production, la mise en cache, par défaut, ?checksum=ba411cafee2f0f702572369da0b765e2).
      • C'est ce qu'il doit faire vivre dès maintenant, embellie assez pour moi de lire (embellie de la production, jamais mis en cache, ?debug_pretty_source=true).
      • C'est ce que j'utilise pour comprendre ce qui n'est pas de faire ce qu'il doit à vivre si elle existe dans les deux précédents (embellie avec debug activé, jamais mis en cache, ACL/liste blanche autorisé, ?debug_dev_enable=true ou similaire).

    Vous pouvez appliquer le même principe aux versions de package en utilisant les numéros de version à la place de sommes de contrôle, à condition que votre versions ne changent pas. Les sommes de contrôle sont moins lisible mais plus facile à automatiser et de conserver la synchronisation avec les changements exacts, mais la version suffixes sont utiles pour tester la stabilité du package aussi, à condition que le numéro de version reflète immuable de ressources.

    Il convient de noter que http transit procurations parfois interférer avec cela à l'aide de GET, qui dépendent de la chemin d'accès réseau à la demande à votre serveur. Dans ce cas, cela peut être contourné en ajoutant de la valeur de hachage directement le nom du fichier au lieu d'utiliser une chaîne de caractères, puis à l'aide d'un .htaccess règle de réécriture pour les dépouiller, qui fonctionne même dans le cas de procuration des interférences. Il n'est généralement pas un problème, mais parfois peut être dans certains cas limites. Par exemple: styles.ba411cafee2f0f702572369da0b765e2.css au lieu de styles.css?checksum=ba411cafee2f0f702572369da0b765e2

    OriginalL'auteur mopsyd

  4. 0

    Trouvé ce alors que la recherche de solution. Pas de joie, il a écrit un peu de javascript pour résoudre le problème qui peut être utile à d'autres.

    Dans <HEAD> au-dessus de toute autre javascript:

    <script>
    if( typeof(opera) != 'undefined' ) { //only do for Opera
       if (window.name == 'previously_loaded') { //will be "" before page is loaded
            alert('Reloading Page from Server'); //for testing
            window.name = ''; //prevent multiple reload
            window.location.reload(true);
       }
    }
</script>

    Maintenant modifier le nom de la fenêtre d'Opéra qu'il détecte sur chargement ultérieur de la mémoire cache:

    window.name = 'previously_loaded';

    Insérer cette ligne dans l'un de vos js blocs que l'habitude d'être exécutées au cours de la fenêtre “charger”, causant une infinie recharger. Pour moi il n'y avait pas besoin de rafraîchir la page à moins que quelqu'un s'est terminé par un lien, donc j'ai juste ajouté ça à mon onclick/onunload fonction.

    Avant et après les démos ici avec un peu plus de notes. J'ai l'intention de l'ajouter à mon blog. J'ai seulement un peu de retard les versions d'Opera, donc j'apprécierais quelques tentatives de la démo avant de me lancer de l'oeuf sur mon visage.

    Edit: Viens de réaliser que si une visité par la suite du changement de nom de la fenêtre (la persistance de l') puis de nouveau-onglet recharger l'habitude de se produire. Changez juste au-dessus si l'instruction pour:

     if (window.name != "") {

    Démo a bien fonctionné lors de l'ouverture de plusieurs onglets; mais j'ai vaguement rappeler que la fenêtre de noms doivent être uniques; j'ai donc modifié la démo pour générer un nom unique.

    window.name = new Date().getTime();

    OriginalL'auteur scytale