¿Es posible eliminar un encabezado de respuesta Pragma sin caché una vez que se haya establecido mediante el método SetCacheability?

Question

Tengo un método de acción MVC4 GET que devuelve FileStreamResult. Un requisito existe para sólo utilizan SSL y para no permitir el almacenamiento en caché del documento servido tan SSL que es y también he utilizado el filtro OutputCache con las siguientes propiedades:

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "None", Location = OutputCacheLocation.None)] 

Esto se comporta como se esperaba y produce la siguiente respuesta encabezados:

Cache-Control: no-cache, no-store 
Expires: -1 
Pragma: no-cache 

Todo fue bien hasta que les pide que apoyen también IE8 y como muchos aquí también se han encontrado con los documentos simplemente no descargarán tanto con no-cache establecer y SSL en la mezcla. El wordaround para IE8 y abajo es para agregar alguna configuración de registro que no es realmente viable, o para eliminar los encabezados sin caché que rompe un requisito fundamental.

Experimenté con Fiddler e IE8 y pude descargar un documento si simplemente eliminaba el pragma: encabezado sin caché pero dejaba intacto el control de caché. Esto no parece dejar una copia del documento en mis archivos temporales de Internet, pero podría necesitar probar esto un poco más.

Con esta información en mente, pensé que podría ser una tarea sencilla eliminar el pragma usando un filtro en la acción, pero parece que no importa lo que haga, no puedo cambiar lo que OutputCache vaya a establecer. Incluso me he quitado el atributo OutputCache y utilicé:

Response.Cache.SetCacheability(HttpCacheability.NoCache) 

uso de este método solo asegura consigo los mismos valores de caché como antes, pero que no se han fijado en el punto de esta llamada al método. Esto simplemente configura la política de caché que se aplica en algún punto de la canalización de respuesta, pero no sé dónde.

¿Alguien sabe si hay una forma de engancharse en la tubería de respuesta para alterar los encabezados de la memoria caché a medida que se escriben?

EDITAR He añadido un simple encargo IHttpModule en la tubería que busca y elimina cualquier encabezado Pragma en el NameValueCollection respuesta y mientras se establece el control de caché del pragma no está allí. ¿Esto significa que IIS 7.5 está insertando el pragma en sí mismo en función de lo que ve en el control de caché, tal vez? Sé con certeza que no he establecido nada más allá de los valores predeterminados para un sitio web simple.

EDITAR comprobado el valor de la cabecera Cache-Control en el módulo y que se fija privada por lo que las cabeceras de caché no se han aplicado a la respuesta todavía. ¿Entonces parece que los encabezados de la caché se agregan después de que se ejecuten los módulos quizás?

Answer 1

Estaba solucionando este mismo problema y me encontré con el mismo problema al eliminar el encabezado pragma. Cuando .NET representa un objeto de página, genera los encabezados de caché. El manejo de la caché está controlado por un HttpModule. He intentado varias formas de eliminar el encabezado pragma, pero fue en vano.

Un método que aún no he probado parece que podría funcionar, pero también parece que un PITA es implementar un filtro en la corriente de salida Response a través de Response.Filter = new MyCustomFilter(...).

Antes de esto traté de comprobar los encabezados en varias ubicaciones, pero el procesamiento de la memoria caché de salida no se había ejecutado aún y el encabezado pragma no existía y, por lo tanto, no se pudo eliminar. Cabe destacar que el evento HttpApplication PreSendRequestHeaders no funcionó.

Algunas otras opciones incluyen la implementación de su propio módulo OutputCache en lugar de utilizar la versión incorporada del marco de trabajo o, de alguna manera, anular la clase System.Web.HttpCachePolicy donde se representa el encabezado pragma.

El encabezado Pragma se representa como parte de la opción HttpCacheability.NoCache:

if (httpCacheability == HttpCacheability.NoCache || httpCacheability == HttpCacheability.Server) 
    { 
    if (HttpCachePolicy.s_headerPragmaNoCache == null) 
     HttpCachePolicy.s_headerPragmaNoCache = new HttpResponseHeader(4, "no-cache"); 
    this._headerPragma = HttpCachePolicy.s_headerPragmaNoCache; 
    if (this._allowInHistory != 1) 
    { 
     if (HttpCachePolicy.s_headerExpiresMinus1 == null) 
     HttpCachePolicy.s_headerExpiresMinus1 = new HttpResponseHeader(18, "-1"); 
     this._headerExpires = HttpCachePolicy.s_headerExpiresMinus1; 
    } 
    } 

La única opción pragmática que he encontrado es configurar la memoria caché y controles para privada y también a un corto de caducidad de la URL. No aborda la causa raíz en ninguno de los extremos, pero termina con casi el mismo efecto deseado.