WebResource.axd y encabezados HTTP

Question

Nuestro sitio apenas se movió de .NET 1.1 a .NET 3.5, y en el proceso actualiza los controles de servidor de 3 ª parte. Uno de estos paquetes utiliza JavaScript proporcionada a través de WebResource.axd. Estos se incluyen como normales <script src="" /> etiquetas.

Mirando el tráfico, sin embargo, veo que estos archivos javascript están llegando a través con cabeceras que impiden la caché del cliente. Y estamos hablando de una gran cantidad de Javascript. Las cabeceras en cuestión:

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

¿Son estas cabeceras configurable en .NET en alguna parte? ¿Puedo interceptar estas solicitudes corta de la construcción de un HttpModule? ¿Es esto algo que puedo echarle la culpa al proveedor de control para? <brandish weapon="blameGun" />

Gracias,

Baron

Answer 1

Usted podría intentar:

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

Los otros tipos de HttpCacheability se documentan aquí:

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

Editar

Usted puede lanzar esto en su archivo Global.asax en lugar de un módulo:

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

Answer 2

Esto puede ocurrir si su sitio web se despliega con <compilation debug="true"> situado en su web.config. El almacenamiento en caché está deshabilitada en este caso para facilitar la depuración de los archivos JavaScript servido como recursos incrustados. La solución es simplemente establecer el atributo de depuración de la etiqueta de compilación en false. Más información se puede encontrar en esta excelente entrada en el blog.

Answer 3

Gracias por sus respuestas. Resultó que ya teníamos la HttpModule que yo no quiero escribir en su lugar, y fue el origen del problema.