iis-7 gzip httpmodule

iis 7 - IIS7: diferencias entre la compresión de contenido estático y dinámico



iis-7 gzip (2)

Al experimentar con la función de compresión de IIS, me pareció que el módulo dinámico y el módulo estático no están tan vinculados al contenido dinámico o estático (especialmente para el módulo dinámico).

Active la compresión para el tipo mime text/html (o text/* ) en el módulo dinámico, y no en el módulo estático. Accede a un archivo .html. Comprueba la respuesta http en el navegador: está comprimido. (Probado en IIS 7.5 en el servidor 2008R2).

Parece que el módulo de compresión dinámica no está limitado al contenido dinámico. Realiza contenido estático comprimido siempre que coincida con su lista de tipos mime y no esté ya comprimido. Por lo tanto, considero que debe entenderse como un "módulo de compresión" dinámico, en el sentido de que se activa en cada respuesta (según sus criterios de tipo mime y en el encabezado de solicitud de accept-encoding ).

Mientras que el módulo de compresión estática se desencadena un poco como un proceso en segundo plano que trabaja en archivos, y comienza a entregar resultados comprimidos solo una vez que los tiene en su caché. Dado que el módulo de compresión estática se ejecuta más lejos en la pila de módulos, maneja la respuesta antes del módulo de compresión dinámica y, por lo tanto, tiene prioridad sobre la dinámica si se ha comprimido la salida para servir.

Por lo tanto, para su caso de uso específico, debe deshabilitar el módulo de compresión estática en el tipo de text/css mime (tenga cuidado de eliminar el text/* también si está presente) para evitar problemas de almacenamiento en caché al vencer su módulo de parches css personalizado.

Además, puede activar la compresión de text/css en el módulo de compresión dinámica para reemplazar el módulo de compresión estática en este caso. Pero, por supuesto, entonces no aprovechará la capacidad de almacenamiento en caché del módulo de compresión estática.

Desafortunadamente, no he encontrado ninguna documentación para respaldar las declaraciones anteriores.

Otra opción podría ser intentar alterar el orden de ejecución del módulo IIS. Tendría que eliminarlos todos en la configuración de su sitio, luego re-agregarlos, insertando su módulo personalizado tal vez antes de la compresión estática. Pero esto podría ser un camino difícil.

IIS admite dos tipos de compresión: compresión de contenido estático y compresión de contenido dinámico . Según applicationHost.config , se manejan mediante diferentes módulos: DynamicCompressionModule (compdyn.dll) y StaticCompressionModule (compstat.dll), y están configurados para comprimir diferentes tipos de solicitudes . Además, supongo que la compresión dinámica no almacena en caché las solicitudes comprimidas, a diferencia de la compresión estática (de manera predeterminada, los archivos comprimidos se guardan en %SystemDrive%/inetpub/temp/IIS Temporary Compressed Files ).

Sin embargo, además de esas diferencias obvias, sospecho que hay algo más. Creo que se enganchan a la tubería de IIS de una manera ligeramente diferente. ¿Alguien tendría un interior en algunos más detalles?

La forma en que me enteré fue que estaba jugando con un módulo personalizado para modificar archivos CSS al vuelo . Cuando se activó la compresión estática (y se configuró para manejar el conjunto predeterminado de archivos, es decir, también texto / css), en la solicitud en caché a mi módulo personalizado se le entregó el contenido ya comprimido. Cuando moví text / css a la lista de solicitud comprimida dinámicamente, todo comenzó a funcionar. Pero me gustaría tener una prueba más sólida de que realmente es la forma correcta de hacerlo. ¿Existen otras consecuencias / problemas conocidos?

Actualización: Creo que puedo tener una teoría de por qué está sucediendo. Puede que no sea 100% correcto, pero al menos puede explicar el comportamiento observado. Creo que el módulo de compresión estática se registra en los siguientes eventos (entre otros):

RQ_MAP_REQUEST_HANDLER RQ_EXECUTE_REQUEST_HANDLER

Luego, cuando se sirve una solicitud de un archivo estático, el módulo de compresión estática en OnMapRequestHandler comprueba si el archivo se ha comprimido antes y si el archivo real no se ha modificado. Si es así, se volverá a asignar la solicitud a sí misma (devolviendo la redirección adecuada utilizando IMapHandlerProvider ). Cuando luego sirve la respuesta en OnExecuteRequestHandler , envía el archivo comprimido. Si, por otro lado, el archivo no se ha comprimido antes o si ha cambiado, no realiza la redirección de la asignación y deja que el módulo de contenido estático sirva la solicitud y luego, más adelante, en OnPostExecuteRequestHandler comprime el contenido (y actualiza su caché) . Como se mencionó anteriormente, no estoy diciendo que esto sea exactamente lo que está sucediendo (no conozco el código fuente), puede ser solo una aproximación. Además, el módulo de compresión dinámica probablemente no haga nada de esto. Simplemente comprime las respuestas salientes a veces después de RQ_EXECUTE_REQUEST_HANDLER.

Su pregunta no es muy clara, así que responderé una pregunta y espero que sea su pregunta.

La intención de la compresión estática es comprimir los archivos que, de lo contrario, se servirían directamente desde el disco duro (Css / images / javascript) y, como tal, comprime cada archivo una vez y guarda el archivo comprimido en el disco. Esto permite un servicio muy rápido y muy barato de contenido comprimido para archivos estáticos que cambian con poca frecuencia. Es una recomendación bastante segura decir que la mayoría de los sitios web deberían tener habilitada la compresión estática.

El objetivo de la compresión dinámica es comprimir las respuestas dinámicas de los módulos ISS (asp, asp.net, php, etc.). Como esta respuesta puede ser diferente para cada solicitud, la salida comprimida no se puede almacenar en caché. Esta característica es nueva de IIS6, aunque el efecto se puede lograr en algunos entornos, por ejemplo, mediante la implementación de un HttpFilter en ASP.Net. Como cada solicitud debe comprimirse sobre la marcha, esto requiere una compresión mucho más intensiva de la CPU que estática. Por lo tanto, si un servidor está enlazado a la CPU, esto puede no ser una buena opción. La mayoría de los sitios están enlazados a redes y / o bases de datos, por lo que a menudo es una buena idea.

Entonces, lo dinámico y lo estático se refieren al contenido y afectan las estrategias que se pueden usar.

Algunas referencias