web-dev-qa-db-fra.com

IIS et contenu statique?

Selon ltra-Fast ASP.NET: Chapter 3 - Caching :

Les fichiers que le navigateur récupère du serveur doivent être stockés dans le cache du navigateur le plus longtemps possible afin de minimiser les allers-retours sur le serveur.

  • Mais comment IIS sait-il ce qu'est un contenu statique réellement et n'est pas?

    Est-ce juste des images, CSS, JS et pas ASPX, ashx ...?

    Où puis-je voir dans IIS ce qui est déjà considéré comme statique et ce qui ne l'est pas?

  • Qu'en est-il du scénario où une page a été déclarée avec <%@ OutputCache en-tête (sans location)? Les fichiers source images, CSS et JS à l'intérieur de celui-ci aussi sont-ils mis en cache avec les mêmes propriétés?

  • En tant que meilleure pratique, je devrais définir une année dans le futur comme délai d'expiration maximum. Je devrais l'utiliser comme valeur par défaut pour tout le contenu statique sur le site

Alors j'ai fait ça:

Set Common HTTP Response Headers

Mais plus tard, après avoir appuyé sur OK, je ne trouve aucun menu récapitulatif qui me montre: à qui J'ai déjà mis un en-tête de réponse (dans ce cas: le dossier css).

actuellement, afin de voir que le dossier css a été appliqué avec les en-têtes de réponse - je dois aller dans le dossier css à nouveau --> En-tête de réponse Http-->Définir les en-têtes communs --> et puis je le vois. Il n'est pas écrit dans le web.config.

Mais si je le fais pour un fichier (Login.aspx par exemple): Je le vois dans web.config:

<configuration>
    <location path="Login.aspx">
        <system.webServer>
            <staticContent>
                <clientCache cacheControlMode="UseExpires" cacheControlMaxAge="1.00:00:00" httpExpires="Fri, 15 Feb 2013 00:00:00 GMT" />
            </staticContent>
        </system.webServer>
    </location>
</configuration>
asp.nethttpcachingiis-7header
45
Royi Namir

Je comprends ta situation. Parfois, sa confusion comment IIS gère un fichier. C'est également différent pour IIS 6 vs IIS 7 et différent pour Classic App Pools et pools d'applications en mode intégré. Mon expérience concerne principalement les pools d'applications intégrés sur IIS 7.5, c'est donc l'environnement sur lequel je peux commenter le plus précisément possible.

Première question

Mais comment IIS sait-il ce qu'est réellement un contenu statique et ce qui ne l'est pas?

Est-ce juste des images, css, js et non ASPX, ashx ...?

Où puis-je voir dans le IIS ce qui est déjà considéré comme statique et ce qui ne l'est pas?

Vous pouvez consulter la liste des gestionnaires de fichiers dans IIS en accédant à votre site Web, puis en cliquant sur "Mappages de gestionnaires". Par défaut, ils sont hérités de la base de données Web.config de base .Net qui se trouve dans un autre emplacement en fonction de la version de votre framework .Net.

  • C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
  • C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config

Si un fichier demandé n'est pas déjà explicitement mappé à un autre gestionnaire, il tombe dans un gestionnaire catch all (*) comme dernière option (System.Web.DefaultHttpHandler) qui détermine s'il s'agit d'un fichier statique ou d'une demande de navigation dans un répertoire. Les fichiers statiques sont donc simplement des fichiers qui ne sont pas déjà liés à un autre gestionnaire. Par exemple, vous verrez que *.aspx est déjà mappé sur System.Web.UI.PageHandlerFactory avant ce gestionnaire par défaut. Il va donc être traité par ce gestionnaire et ne pas être considéré comme un fichier statique. Si vous avez supprimé ce mappage, vous pourriez techniquement servir * .aspx en tant que fichier statique si vous le vouliez vraiment (juste pour la preuve de son fonctionnement).

Mais vous pouvez également répertorier explicitement un type de fichier en tant que fichier statique en ajoutant une entrée dans la section httpHandlers de votre web.config mappant les extensions de fichier à System.Web.StaticFileHandler dans IIS. Par exemple:

<configuration>
  <system.webServer>
    <handlers>
      <add name="StaticHandler" verb="*" path="*.Zip" type="System.Web.StaticFileHandler" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</configuration>

Cet exemple utilise le <system.webServer> section config, donc pour un pool d'applications fonctionnant en mode intégré .

Deuxième question

Qu'en est-il du scénario où une page a été déclarée avec un en-tête <% @ OutputCache (sans emplacement). les images, css, fichiers js src à l'intérieur, sont-elles également mises en cache avec les mêmes propriétés?

Non. Étant donné que la page est en cours de serveur en tant que demande distincte (peut-être même par un gestionnaire distinct), elle peut avoir des en-têtes/conseils de cache totalement différents. La page hôte et les ressources qu'elle peut utiliser ne sont pas liées du point de vue de la mise en cache.

En fait, vous voudrez peut-être même avoir une période de cache plus courte pour * .html et une période de cache plus longue pour * .jpg ou * .png? Quelque chose à considérer.

Troisième question

En tant que meilleur prcatice, je devrais définir une année dans le futur comme délai d'expiration maximum, je devrais l'utiliser comme valeur par défaut pour tout le contenu statique sur le site

Hmm ... Je n'irai peut-être pas aussi loin qu'un an. Que diriez-vous d'un mois? Je définirais une politique globale comme celle-ci:

<configuration>
  <system.webServer>
    <staticContent>
      <!-- Set expire headers to 30 days for static content-->
      <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
    </staticContent>
  </system.webServer>
</configuration>

C'est le même que l'exemple que vous avez montré ci-dessus, mais n'est pas à l'intérieur d'un <location> élément, à la place, il est juste dans la racine <configuration> élément c'est donc la politique par défaut. Encore une fois, cela concerne un pool d'applications fonctionnant en mode intégré . Parfois, vous devez également activer:

<configuration>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true">
            <!-- stuff -->
        </modules>
    </system.webServer>
<system.webServer>

Cela garantit simplement que les fichiers statiques sont traités via le gestionnaire de fichiers statiques gérés qui respecte les éléments de configuration ci-dessus.

Modifier pour répondre aux commentaires

La documentation de la boîte de dialogue de configuration que vous avez publiée ci-dessus se trouve ici: Configurer l'en-tête de réponse HTTP Expires (IIS 7)

Apparemment, ces paramètres sont enregistrés dans C:\Windows\System32\inetsrv\config\applicationHost.config

Je n'ai pas IIS7 et je développe personnellement sur IIS 7.5 maintenant. Veuillez donc poster un commentaire si vous pouvez vérifier que cet emplacement est exact!

69
BenSwayne
  1. Le contenu statique est celui qui IIS est lu et envoyé au navigateur sans aucun traitement. Vous pouvez y configurer IIS pour inclure _ Cache-Control Header pour le mettre en cache sur les ordinateurs des navigateurs clients.
  2. Vous pouvez faire cet éther en configurant directement IIS, ether par des commandes sur web.config comme tu dis. Les commandes que vous ajoutez sur web.config et concernent l'IIS, n'ont pas à voir avec asp.net lui-même, mais avec IIS, et IIS enregistre sa configuration dans un fichier différent, donc lorsque vous modifiez les en-têtes de contrôle du cache directement sur IIS vous ne les voyez pas sur web.config.
  3. Maintenant, pour le contenu statique comme les images, CSS, JavaScript et autres fichiers similaires ils disent que vous pouvez suivre la politique "ne jamais expirer" en ajoutant 10 ans d'expiration.
  4. Le problème ici est que si vous ne pouvez pas modifier le contenu du fichier statique, si par exemple vous mettez en cache un fichier javascript avec 10 ans, et que vous y apportez une petite modification, alors vous avez besoin d'éther pour changer le nom du fichier, ether pour ajoutez un paramètre à la fin de celui-ci.
  5. Maintenant le <%@ OutputCache sur un contrôle est référé au cache du serveur et non au client, et ce qui est réellement fait est de mettre en cache le rendu du contrôle sur le serveur, donc la prochaine fois que vous lui demanderez de ne pas perdre de temps pour le restituer mais lire à partir du cache - est toujours l'envoyer au navigateur.

Et vous pouvez également lire cette réponse pour en savoir plus: Quelle est la différence entre le cache IIS (dynamique et statique), OutPutCache et le cache du navigateur

4
Aristos