Generador y comprobador de cabecera Content-Disposition

Qué hace la cabecera Content-Disposition

Content-Disposition es la cabecera de respuesta que convierte una página en una descarga y le pone nombre al archivo guardado. Tiene una parte obligatoria, el tipo de disposición, y los parámetros que importan aquí son filename y filename*. Un tipo attachment le dice al navegador que pregunte dónde guardar; inline le dice que se comporte con normalidad, y por eso inline solo sirve de algo cuando lleva un nombre pegado: si no, pide exactamente lo que ocurre sin ninguna cabecera.

Hay un tercer caso que conviene conocer porque pasa desapercibido: la RFC 6266 dice que los tipos de disposición desconocidos o no manejados deben tratarse igual que attachment. Así que una errata como attachement no acaba mostrando el archivo, sino descargándolo. Esta herramienta lo señala en vez de dejarlo pasar, porque una cabecera que funciona por casualidad es una que nadie vuelve a mirar.

El nombre del archivo es orientativo en el sentido más fuerte de la palabra. La especificación pide a los destinatarios que vayan con mucho cuidado: que no se fíen nunca de la información de carpetas, que se queden solo con el último segmento de la ruta, que no escriban en ningún sitio que el usuario no haya autorizado y que eliminen o sustituyan los caracteres de control y los espacios de los extremos. Si un navegador te renombró el archivo, estaba siguiendo las reglas.

Cómo usarlo

1. Elige un modo. Crear una cabecera toma el nombre que quieres que vea el visitante y escribe la cabecera. Comprobar una cabecera toma la que ya tienes —pegada con el nombre del campo o sin él— y deduce qué hace un destinatario con ella.
2. En el modo de creación, escribe el nombre tal cual. Con sus tildes y su ñ. Elige attachment o inline, y elige cómo escribe el respaldo ASCII una letra acentuada: la grafía de pasaporte convierte la ä en ae, o puedes quedarte con una sola a. Cópiate la cabecera con el botón.
3. En el modo de comprobación, mira las dos filas que importan. Nombre que se usa es el que guarda de verdad un navegador actual, y Sacado de dice cuál de los dos parámetros lo aportó. Los hallazgos de abajo se dividen en errores, que rompen algo; avisos, que son válidos pero juegan en tu contra; y notas, que son válidas y sencillamente no hacen nada.

Por qué una cabecera correcta manda el nombre dos veces

Esta es la parte que sorprende, y es la razón de ser de la herramienta. La RFC 6266 dice que los dos parámetros se diferencian solo en que filename* usa una codificación que admite caracteres fuera de ISO-8859-1 y, acto seguido —esto es lo decisivo—, que cuando ambos están presentes en un mismo valor de cabecera los destinatarios deben quedarse con filename* e ignorar filename. El consejo no es sustituir uno por el otro. Es mandar los dos.

El motivo es la compatibilidad. La forma extendida llegó cuando ya había mucho software desplegado, así que quien manda solo filename* deja sin nada a lo más antiguo, y quien manda solo filename se queda encerrado en un juego de caracteres que no sabe escribir la mayoría de los nombres del mundo. El apéndice D del mismo documento pone el orden por escrito: incluye filename cuando US-ASCII dé para expresarlo, añade filename* cuando no, genera el respaldo sustituyendo por secuencias ASCII, y pon filename primero, porque algunos analizadores existentes se paran en el primer nombre que entienden.

Ese consejo de sustitución viene con su propio ejemplo —la letra ä pasa a ae—, que es la grafía de pasaporte y no la de una sola letra, y es la que usa esta herramienta por defecto. La tabla que hay detrás es la misma que usa el generador de slugs del sitio, sacada del Doc 9303 de la OACI, y existe porque la receta obvia está mal: normalizar y quitar las marcas de acento borra sin avisar más o menos una docena de letras latinas enteras en vez de plegarlas, así que Ærø queda en la sola letra r y Straße pierde su ß. Aquí Ærø.txt tiene como respaldo AEroe.txt.

El apéndice D también admite el límite de su propio consejo, en una frase: puede que esto no sea posible en algunos idiomas. Un nombre escrito enteramente en japonés o en árabe no tiene grafía ASCII ninguna, así que esta herramienta no se la inventa. Escribe una raíz de marcador, conserva la extensión, enumera todos los caracteres que no ha sabido escribir y lo dice en la página. Cualquier navegador actual lee filename* y obtiene el nombre real de todas formas; el marcador solo lo ve el software realmente antiguo.

El valor extendido no es encodeURIComponent

La codificación de filename* la define la RFC 8187, y no es la codificación de URL, aunque se le parezca lo bastante como para engañar a casi todo el mundo. El valor es un nombre de codificación de caracteres, dos comillas simples y luego una secuencia en la que cada carácter o va con escape de porcentaje o pertenece a un conjunto que la especificación llama attr-char: los caracteres de token menos el asterisco, el apóstrofo y el porcentaje.

Compara ese conjunto con encodeURIComponent, que es a lo que echa mano casi cualquier fragmento de código de ejemplo, y los dos discrepan en ambos sentidos. Barriendo todo ASCII, encodeURIComponent deja intactos exactamente cuatro caracteres que attr-char prohíbe: el apóstrofo, los dos paréntesis y el asterisco. Además escapa siete que attr-char sí permite, lo cual es inofensivo, porque un escape de porcentaje siempre es legal. Los cuatro no son inofensivos, y no son exóticos: informe (final).pdf y O'Brien.pdf son nombres de lo más corriente, y los dos salen de encodeURIComponent llevando un carácter que la gramática no admite.

En el mismo sitio hay una segunda trampa. La RFC 8187 eliminó en su revisión de 2017 la obligación de admitir ISO-8859-1 y ahora dice que los emisores deben usar UTF-8, así que un valor que anuncia otra codificación va por detrás de la especificación aunque siga funcionando. Y el valor extendido no puede ir nunca entre comillas: el mismo documento apunta que un analizador montado con piezas genéricas bien podría aceptar la forma entrecomillada igualmente, que es justo la manera en que un fallo así sobrevive a las pruebas.

Lo que esto no te va a decir

Esto comprueba el texto que pegas y nada más. Un navegador no puede ir a buscar las cabeceras de tu servidor, así que la herramienta no tiene ni idea de si la cabecera que estás mirando es la que se manda, de si el archivo que hay detrás existe, ni de si su tipo de medio cuadra con la extensión. Una cabecera puede ser impecable y describir la respuesta equivocada.

Tampoco dice nada de si el nombre es legal una vez aterriza en el disco. Los nombres de dispositivo reservados, los caracteres que Windows prohíbe y los límites de longitud son otro juego de reglas con otra respuesta, y este sitio tiene un saneador de nombres de archivo para esa pregunta. Los dos problemas se parecen y no comparten nada: este va de sobrevivir a la cabecera, aquel de sobrevivir al sistema de archivos.

Una omisión deliberada: las continuaciones de parámetro, el mecanismo de la RFC 2231 que parte un valor largo entre filename*0* y filename*1*. La RFC 8187 afirma que las continuaciones no hacen falta en las cabeceras HTTP y no las adopta, así que una cabecera que las use queda fuera de lo que esto analiza. Si tienes una, viene de software que sigue una convención MIME más antigua en un sitio que nunca la pidió.

Y para acabar: nada de esto convierte un nombre de archivo en algo vinculante. La especificación insiste en que el destinatario lo trata como un consejo, en que puede sustituir un nombre que signifique algo especial para el sistema de archivos y en que debe asegurarse de que cualquier extensión de la que se fíe sea segura. Lo que compra una cabecera correcta es la mejor probabilidad de que salga el nombre que querías, no la garantía.

¿Por qué es gratis?

Crear y analizar una cabecera es trabajo de texto y corre en tu navegador. No hay ningún servidor de por medio, así que no hay nada que cobrar ni cuenta que crear.

No se sube nada y no se guarda nada. Recarga la página y habrá olvidado tu nombre de archivo.