Usuarios de aplicaciones y sistemas antiguos retrasan la migración de W3C a HTTPS

Más de una década después de la implementación del soporte para conexiones HTTPS seguras en su web, el Consorcio World Wide Web (W3C) está planeando por fin redirigir todas sus conexiones HTTP inseguras a HTTPS. La entidad, que recibe cientos de millones de peticiones por día a su web, no lo había hecho hasta ahora por temor a ocasionar problemas de funcionamiento en aplicaciones web legadas, dado que muchas dependen de recursos a los que acceden a través del protocolo HTTP. Pero ahora asegura que ya está preparada para hacerlo.

Gerald Oskoboiny, Administrador de sistemas de W3C, lo explicaba en un post el pasado día 25 de julio: «la principal razón para no hacerlo es que queríamos evitar problemas al software que hace peticiones de recursos legibles por máquina de www.w3.org, como HTML DTDs, Esquemas XML y documentos de espacio de nombres. Creemos que ha pasado bastante tiempo para que la mayoría del software de este tipo se haya actualizado para gestionar redirecciones y https, por lo que estamos planeando comenzar con la redirección de todas las peticiones recibidas por http a https en uno o dos meses«.

Hace más o menos un mes que fijaron la fecha objetivo para la redirección, pero esta misma semana la han eliminado y han vuelto a dejarla como indeterminada. Esto ha sucedido después de un post de seguimiento al anterior en el que el W3C muestra lo que ha visto en las primeras pruebas del paso de HTTP a HTTPS. Además, según The Register, la nueva fecha dependerá de los resultados de las pruebas de la W3C y del feedback que reciban.

Según Oskobony, las pruebas preliminares han sido bastante problemáticas. El consorcio realizó dos test iniciales de la redirección de HTTP a HTTPS, durante ocho horas el 1 de agosto, y de unas 27 horas el 18 de agosto. En ambos se obtuvieron varios informes de fallos de aplicaciones. De hecho, la segunda prueba estaba programada para durar 72 horas, pero se redujo por «varias quejas de que el cambio estaba teniendo impacto en servicios de producción«.

Los afectados por las pruebas de la redirección señalaron que el cambio «rompió» el código utilizado para validar esquemas XML, un paso opcional pero altamente aconsejable para asegurar que los datos XML se generan de manera adecuada. También fallaron la versiones de la herramienta de Verificación de Driver Estático de Microsoft, al parecer.

De hecho, en el post en el que W3C informa de los resultados de las pruebas, señala que durante las mismas hubo varias personas que se quejaron de que «estaba causando problemas con sus sistemas que hacen peticiones automatizadas a nuestro site. Por ejemplo, al realizar validaciones de Esquemas XML. Esperamos que estos sistemas puedan actualizarse o bien para seguir la redirección a https, o para emplear un catálogo XML para mantener copias locales de todos los archivos que necesiten para evitar hacer peticiones innecesarias a nuestro sistema«.

Algunas de las aplicaciones citadas por los que han enviado sus comentarios emplean componentes de Java, como el paquete java-xml-validation del Java Development Kit (JDK) 11, o java.xml.validation.SchemaFactory del Java Development Kit 8. Estos componentes, a su vez, dependen de software como Apache Xerces, una colección de herramientas open source para la gestión del XML que se usa mucho en Java. También de libxml2, una librería de software open source para el parseado XML.

En el caso de esta última, ya dio problemas hace dos años al pedir compatibilidad con HTTPS. Hace un año, Nick Wellnhofer, que mantiene el proyecto, rechazó una petición para agregar https, alegando que la librería no hace eso porque «es una mala idea cargar recursos en la red, por disponibilidad y rendimiento«. Oskobony está de acuerdo, y ha señalado que «es bueno ser consciente de cualquier dependencia que puedas tener de sitios de terceros. Es sorprendente que el software moderno que hace peticiones HTTPS no tenga la capacidad de gestionar redirecciones o https. Por favor, asegúrate de que tu software está actualizado, y comunica problemas a los desarrolladores si es necesario«.

Hace solo unos días que otro desarrollador pidió a Wellnhofer reconsiderar su decisión por el abandono de la W3C al HTTP, porque «va a romper un montón de herramientas que depenten de libxml2, como lxml, y porque aunque el desarrollador está de acuerdo con él en que «la validación de esquemas por Internet no es eficiente, se utiliza mucho y las soluciones al problema no funcionan muy bien«.

En esta ocasión, Wellnhofer no se ha negado, pero ha señalado que para hacerlo, alguien tiene que prestarse a ello, implementar la función y darle soporte en los próximos años. Vamos, que él no quiere saber nada del asunto. Mientras tanto, el W3C sigue con sus pruebas. La próxima va a durar 48 horas y comenzará el próximo 1 de septiembre.

Foto: Fabio Lanari