Resumo

  • O atributo HTML download pede ao navegador que salve um recurso e sugere um nome; o servidor também pode enviar um nome por HTTP.
  • Registros de Mozilla em 2013 e do WHATWG em 2017 mostram a disputa quando o botão e o arquivo pertencem a origens diferentes.

O arquivo entra na pasta Downloads com a discrição de quem sempre morou ali. Seu nome, porém, passou por uma pequena assembleia. A página que oferece o botão pode ter escrito uma sugestão. O servidor que entregou os bytes pode ter escrito outra. O navegador, responsável por tocar o disco do usuário, precisa decidir qual etiqueta levar a sério. É burocracia em milissegundos, e quase sempre funciona tão bem que ninguém percebe a reunião.

O servidor fala por meio de Content-Disposition. O RFC 6266, publicado em junho de 2011, organizou esse cabeçalho no HTTP: attachment indica tratamento de anexo, filename recomenda um nome e filename* permite caracteres internacionais. O texto do RFC é bem claro sobre a natureza dessa recomendação. Um caminho que inclua diretórios inesperados não dá ao servidor licença para escolher onde gravar no computador alheio. Extensões perigosas e caracteres confusos exigem cuidado do programa que recebe o arquivo. A etiqueta viaja pela rede; a chave da gaveta fica com o navegador.

Depois o HTML pôs uma caneta na mão de quem cria a página. O registro de plataforma do Chromium lista a[download] como disponível no marco M14. O autor pode indicar que aquele link deve iniciar um download e sugerir o nome local no valor do atributo. Faz sentido para uma imagem, um documento ou dados gerados no próprio navegador. A dificuldade aparece quando o link aponta para outro site. A página que anuncia “baixe aqui” não é necessariamente a dona do conteúdo que chega.

Em 2013, um relato no sistema de bugs da Mozilla comparou um link para imagem em outra origem: Firefox abria a imagem, Chrome a baixava. O autor do relato esperava o comportamento do Chrome. A resposta da Mozilla classificou a escolha do Firefox como medida de segurança necessária e encerrou o bug. A diferença era visível na tela, mas nascia de uma pergunta invisível: quem pode transformar conteúdo de um site alheio em arquivo no computador do visitante?

Uma discussão no WHATWG em abril de 2017 mostrou que havia mais de uma forma de responder. Na situação descrita, Firefox e Safari ignoravam o atributo para a origem externa; Chrome fazia o download, mas descartava o nome sugerido pela página. Um editor do padrão observou que o algoritmo da época permitia as duas saídas e propôs aproximar os navegadores. O pedido para baixar e o poder de batizar o arquivo eram decisões separadas. No mesmo ano, o WebKit apresentou o suporte ao atributo no Safari 10.1 para macOS, inclusive para arquivos Blob criados por JavaScript. A conveniência já estava no produto; a conversa sobre suas bordas continuava.

O HTML Standard atual estabelece a coreografia. download expressa a intenção da página e recomenda um nome. O nome enviado por Content-Disposition pode prevalecer. Em downloads entre origens, o attachment enviado pelo servidor do recurso dá um sinal explícito e ajuda a evitar uma surpresa plantada por outra página. O navegador verifica ainda o nome e o destino local.

Por isso um botão de download é um pequeno acordo entre três oficinas. Uma monta a vitrine, outra embala a mercadoria, a terceira recebe a encomenda em casa. O nome final do arquivo é a assinatura que sobrou depois da negociação. Parece detalhe de interface; é a fronteira entre uma página pedindo e um computador aceitando.