Gwtar: formato HTML estático, eficiente y de archivo único

• Un formato de archivo HTML único que permite a los navegadores hacer carga diferida (lazy-loading) de forma eficiente, incluyendo todos los recursos y logrando al mismo tiempo ser estático, de un solo archivo y eficiente
• Combina HTML y un encabezado JavaScript con el HTML original y los recursos en forma de tarball, de modo que el JS carga solo las partes necesarias mediante solicitudes HTTP Range
• Soluciones existentes como SingleFile o MHTML conservan el carácter estático y de archivo único, pero carecen de eficiencia; Gwtar resuelve ese problema
• Funciona solo con funciones estándar del navegador, sin configuración adicional del lado del servidor; en algunos entornos como Cloudflare se maneja con el tipo MIME x-gwtar
• Asegura a la vez la preservación y accesibilidad de páginas HTML grandes, por lo que resulta útil para archivado web a largo plazo y almacenamiento de materiales de investigación reproducibles

---

Resumen de Gwtar

• Gwtar es un nuevo formato de archivo Polyglot compuesto por un único archivo HTML, en el que el navegador carga solo las partes necesarias mediante solicitudes HTTP Range
  • Se usa para servir los grandes archivos HTML de Gwern.net
• El JS del encabezado HTML interrumpe la descarga completa del archivo y carga solo los recursos necesarios mediante solicitudes parciales (range request)
• Como resultado, el servidor entrega un único archivo HTML, pero el usuario descarga solo los recursos que necesita
• Toda la funcionalidad está implementada con funciones estándar del navegador, lo que garantiza compatibilidad futura

El triple dilema de los archivos HTML

• Los archivos HTML tienen una limitación histórica: solo pueden satisfacer dos de estas tres propiedades: ser estáticos, ser de un solo archivo y ser eficientes
  • Por ejemplo: SingleFile es estático y de archivo único, pero ineficiente; WARC es estático y eficiente, pero no es un solo archivo
• Las capturas generadas con SingleFile ofrecen una página estática completa, pero incrustan todos los recursos en Base64, haciendo que el archivo crezca hasta cientos de MB
• Incluso si el usuario solo ve una parte de la página, debe descargar el archivo completo, lo que genera ineficiencia
• Gwern.net intentó resolver esto separando los recursos con deconstruct_singlefile.php, pero se perdió la propiedad de archivo único

Enfoque técnico de Gwtar

• Aprovecha las solicitudes HTTP Range para descargar selectivamente solo partes del archivo
• Adopta una estructura de archivo concatenado que une un encabezado HTML + JS con un tarball detrás
• Usa el comando window.stop() en JS para detener la descarga después del encabezado y luego solicitar solo los recursos necesarios
• El navegador renderiza el contenido como HTML normal, mientras el JS intercepta las solicitudes de recursos y las convierte en solicitudes Range

Generación e implementación

• Es posible convertir HTML de SingleFile a Gwtar con el script PHP deconstruct_singlefile.php
  • También admite recompresión de JPG/PNG/GIF y la adición de datos PAR2 FEC (corrección anticipada de errores)
• Tras ejecutar el JS, el navegador carga mediante solicitudes Range solo los recursos necesarios; si el JS está desactivado, vuelve a descargar el archivo completo
• Al estar basado en estándares, no requiere configuración del servidor ni software adicional, y permite restaurar el contenido desde un solo archivo a un HTML de múltiples archivos

Rendimiento y compatibilidad

• Si no hay soporte para solicitudes Range, se descarga el archivo completo, pero la compresión gzip/Brotli puede compensar la velocidad
• Cloudflare elimina el encabezado Range en respuestas text/html, por lo que Gwern.net lo evita estableciendo el tipo MIME como x-gwtar
• No es posible ver el archivo localmente:
  • Esto también ocurre con SingleFileZ, porque las políticas de seguridad del navegador (como CORS) bloquean las solicitudes JS
  • Aunque es una limitación, se considera un trade-off aceptable, y la navegación local puede resolverse convirtiéndolo a un archivo que no dependa de JS

Funciones ampliadas

• Se pueden adjuntar datos binarios adicionales al final del archivo Gwtar (por ejemplo: FEC, firmas, metadatos)
• Con PAR2 es posible recuperar el archivo si una parte resulta dañada
• Se pueden insertar firmas GPG en forma de comentarios HTML para permitir la verificación de integridad
• En futuras versiones se planean funciones como verificación de hash de recursos, prefetch automático, compresión integrada y soporte para múltiples páginas

Posibilidades de uso

• Es adecuado para páginas HTML grandes o para investigación científica reproducible que incluya datasets (por ejemplo, SQLite3)
• También permite cargar una base de datos directamente en el navegador mediante solicitudes Range para analizarla
• Se propone como un formato de archivado web que asegura al mismo tiempo preservación a largo plazo y accesibilidad

Licencia y desarrollo futuro

• La documentación y el código de Gwtar se publican como dominio público CC-0
• Para futuras versiones (v2) se consideran cambios como FEC obligatorio, compresión integrada, soporte para múltiples documentos y mejor deduplicación

[GN⁺]

Comentarios en Hacker News

• Hoy me enteré por primera vez de window.stop()
  Esta función hace que el navegador deje de cargar más recursos
  Los principales navegadores ya la soportan desde hace más de 10 años (documentación de MDN, Can I Use)
  Se puede ver un ejemplo de uso en esta captura de pantalla
  Organicé más detalles en mi post del blog

  • Si eres desarrollador de SPA, cuesta ver esto como algo mejor que APIs como document.write o window.open
    Aun así, podría ser un enfoque interesante si quieres implementar descargas o lazy-loading tú mismo desde una lógica centrada en el servidor
    Fuera de casos especiales como scripts de inicialización o redirección, es difícil recomendarlo
  • Me pregunto si esto será compatible con Claude Artifacts
    Yo publico archivos como fragmentos comprimidos en base64 mediante un bundler que hice, así que se parece a este enfoque
    Si llegara a funcionar en este tipo de entorno de compartición de archivo único, me da la impresión de que la plataforma podría bloquearlo
  • Yo tampoco conocía esta función hasta ahora
    PHP también tiene algo parecido con __halt_compiler(), y lo he usado para meter documentación o datos al final de un archivo sin comentarios

• Al principio me pareció interesante, pero dudé cuando vi que este formato no se puede abrir directamente como archivo local
  Si es un formato de archivo para conservación, el acceso local debería ser uno de los casos de uso principales

  • Yo pienso lo mismo. Esperaba que, como asm.js, aprovechara capacidades ya integradas en el navegador para abrir nuevas posibilidades
    Pero si no se puede abrir directamente en local, gran parte de esa ventaja se pierde (ver el concepto de backdoor pilot)
  • Me imagino que se podría resolver con un programa visor o con un servidor HTML estático sencillo
  • En realidad, HTML por sí mismo ya es un excelente formato de archivo único
    Imágenes, CSS y JS se pueden incrustar con data-uri, y las fuentes también
    De hecho, creo que los formatos de documentos de procesadores de texto serían más flexibles si hubieran usado HTML
  • Con un comando como python -m http.server puedes levantar un servidor local y resolverlo fácilmente
    También se puede con un comando de Claude

• Si el autor llega a ver esto, me gustaría que al formato de archivo le agregara un campo de captura de pantalla en BASE64, un campo de descripción y una marca de tiempo ISO
  Mejor aún, sería ideal poder guardar varias versiones de la misma URL y tener una función de eliminación de activos duplicados

• No entiendo por qué el autor veía a WARC de forma negativa
  De hecho, Gwtar me parece más complejo y menos flexible

  • Pero WARC no puede ofrecer una URL que puedas abrir directamente en el navegador con un clic para ver el contenido
  • Otra razón que se mencionó en otro comentario es que WARC/WACZ son estáticos y eficientes, pero no se pueden mostrar directamente como archivo único, y requieren una instalación aparte y compleja, como WebRecorder

• Me da curiosidad por qué dijo que el formato polyglot ZIP/HTML de SingleFile es “estático y único, pero ineficiente”
  Quisiera saber en qué sentido es menos eficiente que Gwtar

  • La eficiencia aquí se refiere a la capacidad de descargar solo los activos necesarios de forma parcial
    La clave es si el navegador puede traer únicamente las partes que necesita mediante range request, en vez de bajar todo el archivo

• Es una idea realmente genial
  Yo creo que una webapp HTML de archivo único es la forma de software más durable que existe
  Algunos ejemplos que hice son FuzzyGraph y HyperVault

• Yo también había pensado en implementar algo parecido a nivel de Service Worker
  La idea sería dejar la página tal cual y capturar todas las solicitudes HTTP
  Sería una estructura donde, como con window.stop(), solo recibes una parte del HTML y el resto se maneja como blobs de activos
  Si además metes el propio Service Worker como dataURI, se vuelve un archivo único completo

• Es interesante, pero no termino de ver por qué haría falta lazy load en archivos locales
  ¿El archivo va a ser tan grande? ¿O la idea es mantener tal cual una funcionalidad ya implementada?

  • En realidad, el objetivo no son archivos locales sino archivos grandes alojados en un servidor HTTP
    Hace falta range request para pedir solo las partes necesarias sin descargarlo todo por la red
    Claro, dividirlo en varios archivos es lo más común, pero a veces manejar un único archivo resulta más cómodo
    Probablemente también tenga que ver con la estructura del sitio basado en MediaWiki de Gwern

• Hace tiempo yo también hice algo parecido — un proyecto llamado Zundler, aunque era un enfoque bastante hacky
  Funciona en local, pero al principio hay que descomprimir todo

  • Esto se ve como un archivo estático HTML único al estilo de SingleFileZ, pero en una forma que también se puede ver fácilmente en local
    Aun así, me da curiosidad cómo lograron esquivar las restricciones de seguridad
    La explicación solo menciona el tema del origen único (single-origin), así que no termino de entenderlo por completo