Gabriel Rodriguez Plancarte

IIS 7 Logo

Por lo general, IIS trae preconfigurados los SSI (Server Side Includes) para los archivos de tipo .shtml. Sin embargo, puede haber ocasiones en que estemos agregando funcionalidad de SSI a un sitio ya existente, y cuyos archivos tenian extensiones .html.

Para estos casos, lo que tenemos que hacer es agregar un Module Mapping en IIS para que los archivos con extension .html sean manejados por el modulo correcto. Como todo, hay algunos detalles que si no se hacen de cierta manera, las cosas no van a funcionar. Batallé como 2 horas para hacer funcionar esto, así que lo escribo por si a alguien le ahorra tiempo.

Pasos para hacer funcionar SSI para archivos HTML en IIS 7

1. Start -> Run -> inetmgr -> enter.
2. En el arbol/menu de la izquierda, seleccionar la aplicacion especifica que queremos configurar. Si no se selecciona una aplicación en especifico, estaríamos modificando los mappings para todo IIS, y puede que no sea esto lo que queramos.
3. Doble click en Handler Mappings

IIS 7 Handler Mappings

4. Podemos notar que ya existen 3 Mappings con el prefijo SSINC, para los archivos de tipo .shtml, .stm y .shtm
5. Hacemos click derecho en cualquier mapping, y seleccionamos la opción Add Module Mapping.

Module Mappings de SSI en IIS 7

6. Llenamos el campo Request Path con el valor *.html, para que aplique para todos los archivos .html.

Nuevo Module Mapping para SSI en IIS 7

7. En el campo Module, seleccionamos la opción de ServerSideIncludeModule.
8. Y en el campo de Name, para ser consistentes con las otras extensiones, podemos usar el valor SSINC-html.
9. Hacemos click en el botón de Request Restrictions.
10. Activar el checkbox de “Activate Handler only if request is mapped to“, y seleccionar la opción de File.

Request Restrictions para el Module Mapping de SSI

Ahora, IIS ya está configurado. Pero hay un par de detalles más que hay que tomar en cuenta.

Se pueden llegar a topar con el error “Error processing SSI file” de IIS.

Para solucionar esto yo tuve que hacer 2 cosas:

1.Asegurarse que el usuario IIS_IUSRS tenga acceso total al folder donde esta físicamente el sitio.

IIS 7 SSI Correct File Permissions

2. En el archivo HTML, al hacer el include, usar la opción file en lugar de virtual.

Usar file en lugar de virtual al hacer un include de SSI en IIS

[Update] Se me olvidó mencionar que obviamente, como este Mapping hace que todos los archivos .html sean interpretados por el modulo de Server Side Include, estamos haciendo que IIS ya no trate los archivos .html como si fueran estaticos, lo cual implica una mínima perdida de performance de compresión, y un mínimo overhead de procesamiento para los archivos HTML solamente. Para mas información, pueden leer el cuarto comentario de este link, hecho por un MVP de IIS: Enable SSI to include an HTML File.

Y eso es todo…espero les sirva. Si tienen dudas o problemas, dejen un comentario.

.NET Logo

Estoy trabajando en adaptar un diseño HTML/CSS a una aplicación existente de ASP.NET, en Webforms.

Ya estando casi todo lo visual adaptado, y viendose bien, me faltaba transformar una forma de log-in a mark-up de XML, para poder hacer el código de Login.

Como el usuario debía poder loggearse desde cualquier ASPX de la parte pública, decidi transformar los controles de log-in originales en un ASP.NET User Control (ASCX), para poder tener la logica de todo el log-in en un solo lugar, y poder reutilizar el User Control en todas las paginas publicas.

Cree el puro ASCX con el Markup, y abri la pagina en IE. Todo bien.

Convertí el <input type=”button”> a un <asp:ImageButton>.  Error, tengo que agregar la etiqueta de <form runat=server>.

Agregué la etiqueta, View in Browser, no mas error, pero todo el contenido del panel derecho se desplazó hacia abajo.

Despues de batallar como 1 hora con el problema, e intentar googlear, me topé con un artículo que tenía como título “Multiple forms causing strange CSS problem“. Pero yo no tengo multiples formas (eso creí), así que lo ignoré.

Despues de media hora de moverle…recordé que todo el problema empezó cuando agregué la etiqueta de <form runat=server> al ASPX. Regreso al mark-up del User Control (ASCX) y ahi estaba…no había borrado la etiqueta de <form> original al momento de pasar el HTML de la forma de log-in.

Borre la etiqueta de <form> del User Control, y listo…el diseño se ve bien otra vez.

Así que como moraleja….Tener mas de una etiqueta <form> en una ASP.NET Webform te genera problemas raros de CSS.

Hace poco estaba pensando en posibles preguntas para usar en entrevistas de trabajo que me toca hacer de vez en cuando a desarrolladores orientados a aplicaciones web.

Ésta fue una de las que se me ocurrió, y me dio risa la coincidencia de ver un post escrito sobre esto practicamente al mismo tiempo que pensé en la pregunta.

Alguien que realmente ha desarrollado aplicaciones web tiene que conocer las principales diferencias a la hora de programar Javascript para los navegadores principales, los work-arounds, hacks, etc.

ImpressiveWebs: 7 JavaScript Differences Between Firefox & IE