Resumen

  • RFC 9842 permite que una respuesta HTTP sea diccionario externo para solicitudes futuras si superan pruebas de origen, patrón de URL, destino y vigencia.
  • El hash del diccionario, la señal Available-Dictionary, la selección de codificación, la variante de caché y el significado de la respuesta no son un mismo hecho.

Una respuesta pequeña puede producir una conclusión demasiado grande. Cuando un cliente conserva un recurso anterior y un servidor usa ese recurso como diccionario, el tráfico posterior puede comprimirse mejor. Eso no elimina la diferencia entre poseer una entrada de caché, ofrecer una capacidad, seleccionar una representación, decodificarla y decidir qué hacer con ella.

RFC 9842 abre la secuencia con Use-As-Dictionary. El servidor puede declarar que una respuesta sirve como diccionario para futuras solicitudes que cumplan sus reglas. El miembro match es obligatorio y se valida como patrón de URL de la misma origen; match-dest puede limitar destinos de Fetch; id y type aportan datos acotados. El identificador debe tratarse como una cadena opaca. El RFC también impide que el servidor use ese identificador como garantía del contenido. Por tanto, una etiqueta no es una firma de la respuesta y mucho menos una autorización.

Después interviene la evaluación del cliente. Debe disponer de un diccionario fresco, o autorizado para uso obsoleto, y comprobar origen, destino y coincidencia de URL. Si hay varios candidatos, debe escoger uno según prioridades definidas. El resultado es modesto y útil: un diccionario local puede anunciarse en esta solicitud. No significa que el recurso de destino ya exista, que sea correcto para el negocio o que el usuario pueda actuar sobre él.

El cliente anuncia una sola huella SHA-256 del mejor diccionario coincidente mediante Available-Dictionary. Si decide ofrecer compresión con diccionario, añade dcb o dcz a Accept-Encoding. Esta señal describe una capacidad condicionada del cliente. No obliga al servidor a usarla. Tampoco dice qué representación escogerá el servidor, si la respuesta refleja un estado actual, o si una aplicación la interpretará como permiso, instrucción o resultado.

La siguiente decisión pertenece al servidor. Puede usar una representación sin diccionario, otro content coding, o dcb/dcz cuando soporta la alternativa ofrecida y elige el diccionario anunciado. Los formatos incorporan la huella del diccionario antes del flujo Brotli o Zstandard. Eso vincula bytes de referencia con bytes comprimidos. No vincula la respuesta con la voluntad de una persona, con la validez de un precio, con un derecho de acceso, con una configuración efectiva ni con una consecuencia.

La variación de caché es una salvaguarda, no un veredicto. Si una respuesta comprimida con diccionario es cacheable, RFC 9842 exige Vary sobre Accept-Encoding y Available-Dictionary. Así una caché no entrega a un cliente incompatible un flujo que no puede descodificar, ni reutiliza una respuesta construida con otro diccionario. Pero esa clave no contiene necesariamente la información que necesita una decisión de negocio. Una variante HTTP técnicamente correcta puede ser inapropiada para un derecho que cambió, un dato que caducó fuera de HTTP o una acción irreversible.

Las restricciones de seguridad sostienen la misma separación. El transporte se limita a contextos seguros. El emparejamiento se mantiene en la misma origen. Si fallan mitigaciones requeridas, el cliente debe descartar la respuesta. El RFC advierte que mezclar datos públicos y privados en compresión puede filtrar información por longitud o tiempo, y ordena tratar hashes de diccionario como estado sensible al seguimiento, con partición y limpieza semejantes a las cookies. Ninguna de estas medidas transforma el mecanismo en una autorización.

Incluso el enlace compression-dictionary es sólo una posibilidad: invita al cliente a recuperar un recurso que quizá ayude más tarde. El cliente determina si lo recupera; el recurso descargado aún necesita Use-As-Dictionary y metadatos de caché. Un enlace no prueba descarga, coincidencia, uso ni efecto.

El registro operativo debe conservar cada eslabón: recurso y hash, prueba de origen y frescura, destino, anuncio del cliente, elección de codificación, variante, resultado de decodificación, semántica de la respuesta y acción posterior. Esa disciplina protege el valor de RFC 9842. Optimizar la entrega no autoriza a saltar desde un diccionario a una conclusión.

Fuentes