Gwtar: formato HTML estático, eficiente e em arquivo único

• Um formato de arquivo HTML único que permite ao navegador fazer lazy-loading de forma eficiente, incluindo todos os ativos e alcançando ao mesmo tempo as qualidades de ser estático, único e eficiente
• Combina o HTML original e os ativos em forma de tarball após os cabeçalhos de HTML e JavaScript, com uma estrutura em que o JS carrega apenas as partes necessárias via requisições HTTP Range
• Soluções existentes como SingleFile e MHTML têm caráter estático e de arquivo único, mas carecem de eficiência; o Gwtar resolve isso
• Funciona apenas com recursos padrão do navegador, sem configuração adicional no servidor; em alguns ambientes, como o Cloudflare, lida com isso usando o tipo MIME x-gwtar
• Garante ao mesmo tempo preservação e acessibilidade para páginas HTML grandes, sendo útil para arquivamento web de longo prazo e armazenamento de materiais de pesquisa reproduzíveis

---

Visão geral do Gwtar

• Gwtar é um novo formato de arquivo Polyglot composto por um único arquivo HTML, no qual o navegador carrega apenas as partes necessárias por meio de requisições HTTP Range
  • Usado para disponibilizar grandes arquivos HTML do Gwern.net
• O JS no cabeçalho HTML interrompe o download do arquivo completo e busca apenas os ativos necessários por requisições parciais (range request)
• Como resultado, o servidor fornece apenas um único arquivo HTML, mas o usuário baixa somente os ativos de que precisa
• Toda a funcionalidade é implementada com recursos padrão do navegador, garantindo compatibilidade futura

O trilema dos arquivos HTML

• Arquivos HTML têm uma limitação tradicional: só conseguem satisfazer duas entre estaticidade, arquivo único e eficiência
  • Ex.: SingleFile é estático e único, mas ineficiente; WARC é estático e eficiente, mas não é um arquivo único
• Snapshots gerados com SingleFile fornecem uma página totalmente estática, mas embutem todos os ativos em Base64, fazendo o arquivo crescer para centenas de MB
• Isso gera a ineficiência de o usuário precisar baixar o arquivo inteiro mesmo vendo apenas parte da página
• Para resolver isso, o Gwern.net separou os ativos com deconstruct_singlefile.php, mas perdeu a característica de arquivo único

Abordagem técnica do Gwtar

• Usa requisições HTTP Range para permitir download seletivo de apenas partes do arquivo
• Adota uma estrutura de arquivo concatenado, combinando HTML + cabeçalho JS com um tarball em seguida
• Usa o comando window.stop() no JS para interromper o download após o cabeçalho e então requisitar apenas os ativos necessários
• O navegador renderiza como se fosse HTML comum, enquanto o JS intercepta as requisições de ativos e as converte em requisições Range

Geração e implementação

• O script PHP deconstruct_singlefile.php pode converter HTML do SingleFile em Gwtar
  • Suporta recompressão de JPG/PNG/GIF e adição de dados PAR2 FEC (forward error correction)
• Após executar o JS, o navegador busca apenas os ativos necessários via requisições Range; se o JS estiver desativado, recorre ao download do arquivo inteiro
• Por ser baseado em padrões, não exige configuração do servidor nem software adicional, e permite restaurar o arquivo único de volta para HTML com múltiplos arquivos

Desempenho e compatibilidade

• Se requisições Range não forem suportadas, o arquivo inteiro será baixado, mas a velocidade pode ser compensada com compressão gzip/Brotli
• O Cloudflare remove o cabeçalho Range de respostas text/html, então o Gwern.net contorna isso definindo o tipo MIME como x-gwtar
• Não é possível visualizar o arquivo localmente :
  • Isso também vale para o SingleFileZ, porque políticas de segurança do navegador (como CORS) bloqueiam as requisições JS
  • Embora seja lamentável, isso é considerado um trade-off aceitável, e a navegação local pode ser resolvida convertendo para arquivos que não dependam de JS

Recursos de extensão

• É possível anexar dados binários adicionais ao fim do arquivo Gwtar (ex.: FEC, assinaturas, metadados)
• Com PAR2, é possível recuperar o arquivo em caso de corrupção parcial
• É possível verificar a integridade inserindo assinaturas GPG em forma de comentário HTML
• Em versões futuras, estão planejados verificação de hash dos ativos, prefetch automático, compressão embutida e suporte a múltiplas páginas

Possibilidades de uso

• Adequado para páginas HTML grandes ou pesquisas científicas reproduzíveis contendo datasets de pesquisa (ex.: SQLite3)
• É possível carregar bancos de dados diretamente no navegador via requisições Range para análise
• É proposto como um formato de arquivamento web que assegura ao mesmo tempo preservação de longo prazo e acessibilidade

Licença e desenvolvimento futuro

• A documentação e o código do Gwtar são publicados em domínio público CC-0
• Para versões futuras (v2), estão em análise itens como FEC obrigatório, compressão embutida, suporte a múltiplos documentos e melhorias na deduplicação

[GN⁺]

Comentários no Hacker News

• Hoje descobri window.stop() pela primeira vez
  Essa função faz o navegador parar de carregar mais recursos
  Os principais navegadores já a suportam há mais de 10 anos (documentação do MDN, Can I Use)
  Dá para ver um exemplo de uso nesta captura de tela
  Organizei mais detalhes no meu post do blog

  • Para desenvolvedores de SPA, é difícil dizer que isso é melhor do que APIs como document.write ou window.open
    Ainda assim, pode ser uma abordagem interessante se você quiser implementar downloads ou lazy-loading manualmente em lógica centrada no servidor
    Fora situações especiais, como scripts de inicialização ou redirecionamento, é difícil recomendar
  • Fico me perguntando se isso seria compatível com Claude Artifacts
    Eu publico arquivos em forma de chunks base64 compactados por meio de um bundler que fiz, então isso parece parecido
    Se funcionar em ambientes de compartilhamento de arquivo único como esse, acho que a plataforma talvez passe a bloquear isso
  • Eu também nunca tinha visto essa funcionalidade antes
    O PHP tem algo parecido, __halt_compiler(), e eu já usei isso para colocar documentação ou dados no fim do arquivo sem comentários

• No começo achei interessante, mas hesitei quando vi que esse formato não abre diretamente como arquivo local
  Se é um formato de arquivamento, acesso local deveria ser um dos principais casos de uso

  • Também penso assim. Eu esperava que, como o asm.js, isso pudesse abrir novas possibilidades aproveitando recursos já embutidos no navegador
    Mas, se não pode ser aberto localmente de imediato, essa vantagem diminui bastante (veja o conceito de backdoor pilot)
  • Acho que isso poderia ser resolvido com um programa visualizador ou um servidor HTML estático simples
  • Na verdade, o próprio HTML já é um excelente formato de arquivo único
    Imagens, CSS e JS podem ser todos embutidos com data-uri, e fontes também
    Aliás, formatos de documento de processadores de texto talvez fossem mais flexíveis se usassem HTML
  • Dá para resolver facilmente subindo um servidor local com um comando como python -m http.server
    Também dá para fazer isso com um comando do Claude

• Se o autor vir este post, eu gostaria que adicionasse ao formato de arquivo um campo de captura de tela em BASE64, um campo de descrição e um timestamp ISO
  Indo além, seria ideal poder salvar várias versões da mesma URL e ter remoção de ativos duplicados

• Não entendi por que o autor vê WARC de forma negativa
  Na verdade, Gwtar parece mais complexo e menos flexível

  • Mas o WARC não oferece uma URL em que você possa simplesmente clicar e ver o conteúdo direto no navegador
  • Outro motivo mencionado em outro comentário é que WARC/WACZ são estáticos e eficientes, mas não podem ser exibidos diretamente como arquivo único, e exigem uma instalação separada e complexa, como o WebRecorder

• Gostaria de entender por que o formato polyglot ZIP/HTML do SingleFile foi descrito como “estático e único, mas ineficiente”
  Queria saber em que ele é ineficiente em comparação com o Gwtar

  • A eficiência aqui significa a capacidade de baixar parcialmente apenas os ativos necessários
    O ponto principal é se o navegador consegue buscar só as partes necessárias com range request, sem baixar o arquivo inteiro quando faz uma solicitação

• É uma ideia realmente ótima
  Acho que webapps HTML de arquivo único são a forma de software mais duradoura que existe
  Alguns exemplos que criei são FuzzyGraph e HyperVault

• Eu também pensei em implementar algo parecido no nível de Service Worker
  A página permaneceria igual, e todas as requisições HTTP seriam interceptadas
  A estrutura seria como window.stop(), recebendo apenas parte do HTML e tratando o resto como blobs de ativos
  Se o próprio Service Worker fosse colocado como dataURI, isso poderia virar um arquivo único completo

• É interessante, mas não entendo bem por que seria necessário lazy load em arquivos locais
  O arquivo vai ficar tão grande assim? Ou a ideia é apenas manter uma funcionalidade já implementada?

  • Na prática, o alvo não são arquivos locais, e sim arquivos grandes hospedados em servidor HTTP
    Para não baixar tudo pela rede, é preciso usar range request para pedir só as partes necessárias
    Claro, dividir em vários arquivos é mais comum, mas às vezes é mais prático gerenciar um arquivo único
    Talvez isso também tenha relação com a estrutura do site baseado em MediaWiki do Gwern

• Eu também fiz algo parecido no passado — um projeto chamado Zundler, que seguia uma abordagem bem hacky
  Funciona localmente também, mas no começo precisa descompactar tudo

  • Isso parece um arquivo estático HTML único como o SingleFileZ, mas em um formato que também pode ser visto facilmente localmente
    Só fiquei curioso sobre como as restrições de segurança foram contornadas
    Como a descrição só menciona a questão de single-origin, não foi fácil entender completamente