2009-04-09 4 views
2

Notre site vient de passer de .NET 1.1 à .NET 3.5, et a mis à jour nos contrôles serveur tiers. L'un de ces paquets utilise javascript fourni via WebResource.axd. Ceux-ci sont inclus en tant que tags <script src="" /.WebResource.axd et en-têtes HTTP

En regardant le trafic, cependant, je vois que ces fichiers javascript rencontrent des en-têtes qui empêchent la mise en cache côté client. Et nous parlons beaucoup de javascript. Les en-têtes en question:

 
Cache-control: no-cache, no-store 
pragma: no-cache 
Expires: -1 

sont ces en-têtes configurables dans .NET quelque part? Puis-je intercepter ces requêtes à court de construire un HttpModule? Est-ce quelque chose que je peux reprocher au vendeur de contrôle? <brandish weapon="blameGun" />

Merci,

Baron

Répondre

6

Vous pouvez essayer:

HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.Public); 

Les autres types de HttpCacheability sont documentés ici:

http://msdn.microsoft.com/en-us/library/system.web.httpcacheability.aspx

Edit:

Vous pouvez jeter dans votre fichier Global.asax au lieu d'un module:

void Application_AuthorizeRequest(object sender, EventArgs e) 
{ 
    if (Request.Path.IndexOf("WebResource.axd") > -1) 
    { 
     Response.Cache.SetCacheability(HttpCacheability.Public); 
    } 
} 
5

Cela peut se produire si votre site Web est déployé avec <compilation debug="true"> dans son ensemble web.config. La mise en cache est désactivée dans ce cas pour faciliter le débogage des fichiers JavaScript utilisés en tant que ressources intégrées. La solution consiste simplement à définir l'attribut debug de la balise de compilation sur false. Plus d'informations peuvent être trouvées dans this excellent blog.

0

Nous vous remercions de vos réponses. Il s'est avéré que nous avions déjà le HttpModule que je ne voulais pas écrire, et c'était la source du problème.

Questions connexes