Se usó la API de Cloud Translation para traducir esta página.

Compatibilidad con los encabezados de respuesta HTTP

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. info

En este tema, se describe cómo Edge maneja los encabezados de almacenamiento en caché HTTP/1.1 cuando se usa la política ResponseCache. Actualmente, Apigee Edge admite un subconjunto de directivas y encabezados de almacenamiento en caché HTTP/1.1 (las funciones que no son compatibles se enumeran en este tema) recibidas del destino del backend (servidores de origen).

Además, con ciertos encabezados, Edge realiza acciones en función de sus directivas. En algunos casos, estos encabezados de almacenamiento en caché HTTP/1.1 anulan cualquier comportamiento especificado en la política ResponseCache. Por ejemplo, si el encabezado Cache-Control se muestra desde un servidor de backend, puedes hacer que la directiva s-maxage del encabezado anule otras configuraciones de vencimiento en la política.

Nota: Usa encabezados para influir en las claves de caché y el TTL de entrada de caché. Puedes hacer que Edge use encabezados de respuesta cuando construyes claves de caché de respuesta y configuras el TTL de entrada de caché. Para hacerlo, debes usar los siguientes elementos de marca de la política ResponseCache:

<UseResponseCacheHeaders>: Cuando se configura como true, Edge considerará los encabezados de respuesta HTTP que se usaron cuando se configuró el “tiempo de actividad” (TTL) de la respuesta en la caché. Para obtener más detalles, consulta "Configura el vencimiento de las entradas en caché" y <UseResponseCacheHeaders> en la Política de caché de respuesta.
<UseAcceptHeader>: Cuando se configura como true, Edge usará encabezados Accept de respuesta para mejorar la clave de caché. Para obtener más información, consulta <UseAcceptHeader> en la Política de caché de respuesta.

Encabezado	Asistencia
Cache-Control	Es compatible con las respuestas que se muestran desde servidores de origen de backend, pero no desde solicitudes de clientes. Edge admite un subconjunto de directivas.
Vencimiento	Compatible. Se puede anular.
Etiquetas de entidad (ETags)	Es el comportamiento específico para If-Match y para If-None-Match.
If-Modified-Since	En las solicitudes GET, el encabezado se pasa al servidor de origen, incluso si existe una entrada de caché válida.
Accept-Encoding	Edge envía respuestas comprimidas o sin comprimir, según los encabezados entrantes.

Cache-Control

Apigee Edge admite el encabezado Cache-Control solo en las respuestas que se muestran desde los servidores de origen de backend (la especificación HTTP/1.1 permite encabezados Cache-Control en las solicitudes de clientes y las respuestas del servidor de origen). En los servidores de origen, se pueden incluir los extremos de destino definidos en un proxy de API de Apigee Edge y los creados mediante llamadas a la API de TargetServer.

Limitaciones de compatibilidad del control de caché

Apigee Edge admite un subconjunto de capacidades de encabezados de respuesta Cache-Control definidas en la especificación HTTP/1.1. Ten en cuenta lo siguiente:

Apigee Edge no es compatible con los encabezados Cache-Control que llegan con las solicitudes entrantes del cliente.
Apigee Edge solo admite la noción de las cachés públicas. Según la especificación HTTP, Cache-Control puede ser pública (compartida) o privada (deun solo usuario).
Apigee Edge solo admite un subconjunto de directivas de respuesta Cache-Control en la especificación HTTP/1.1. Consulta Compatibilidad con las directivas de encabezados de respuesta de control de caché para obtener más información.

Compatibilidad con las directivas de encabezados de respuesta de control de caché

Apigee admite las directivas de un subconjunto de la especificación HTTP/1.1 en las respuestas de los servidores de origen. En la siguiente tabla, se describe la compatibilidad de Apigee Edge con las directivas de encabezados de respuesta de control de caché HTTP.

Para obtener más información detallada sobre las directivas que se enumeran aquí, consulta el control de caché en la especificación HTTP/1.1.

Directiva de control de caché	Cómo Apigee Edge procesa la directiva
`cache-extension`	No compatible.
`max-age`	Si la política ResponseCache configura el elemento `<UseResponseCacheHeaders>` como `true`, la respuesta se puede almacenar en caché durante la cantidad de segundos que especifica esta directiva. Esta directiva es anulada por la directiva `s-maxage` y anula el encabezado `Expires`. También se puede anular mediante el elemento `<ExpirySettings>` de la política. Para obtener más información, consulta “Configura el vencimiento de las entradas en caché” y `<UseResponseCacheHeaders>` en la política de caché de respuesta. Nota: El contenido que se almacena en caché con la política ResponseCache mantendrá el valor max-age que estableció su origen. Esto significa que, cuando se recupera de la caché, es posible que el contenido tenga una antigüedad superior a la que indica el valor max-age (superior de lo que el cliente sabe).
`must-revalidate`	No compatible. Apigee Edge borrará todas las entradas de caché ni bien se venzan.
`no-cache`	Edge almacena en caché la respuesta del origen, pero debe volver a validarse con el servidor de origen antes de usarse para satisfacer cualquier solicitud posterior del cliente. Esta regla permite que el origen muestre una respuesta 304 Sin modificar a fin de indicar que la respuesta se debe mostrar desde la caché, y de esa forma evitar el procesamiento requerido para mostrar la respuesta completa. Si el servidor de origen muestra una respuesta completa, reemplaza la entrada de caché existente. Se ignorará cualquier nombre de campo especificado con esta directiva. Nota: El encabezado HTTP/1.0, `Pragma: no-cache`, se trata como equivalente a `Cache-Control: no-cache`.
`no-store`	No compatible.
`no-transform`	No compatible.
`private`	No compatible. Si se recibe esta directiva, la respuesta del origen no se almacenará en caché. Se ignorará cualquier nombre de campo.
`proxy-revalidate`	No compatible. Apigee Edge borrará todas las entradas de caché ni bien se venzan.
`public`	Edge almacena en caché la respuesta del origen, incluso cuando otras directivas indican lo contrario. Según la especificación HTTP/1.1, la única excepción a esta regla es si en la respuesta seincluye un encabezado de autorización.
`s-maxage`	Si la política ResponseCache configura el elemento `<UseResponseCacheHeaders>` como `true`, la respuesta se puede almacenar en caché durante la cantidad de segundos que especifica esta directiva. Esta directiva anula la directiva `max-age` y el encabezado `Expires`. Se puede anular mediante el elemento `<ExpirySettings>` de la política. Para obtener más información, consulta “Configura el vencimiento de las entradas en caché” y `<UseResponseCacheHeaders>` en la política de caché de respuesta. Nota: El contenido que se almacena en caché con la política ResponseCache mantendrá el valor s-maxage que estableció su origen. Esto significa que, cuando se recupera de la caché, es posible que el contenido tenga una antigüedad superior a la que indica el valor s-maxage (superior de lo que el cliente sabe).

Vencimiento

Cuando la marca UseResponseCacheHeaders de la política ResponseCache se configura como true, Edge puede usar el encabezado Expires para determinar el tiempo de actividad (TTL) de una entrada almacenada en caché. Este encabezado especifica una fecha y una hora después de las cuales la entrada de caché de una respuesta se considera inactiva. Este encabezado permite que los servidores indiquen cuándo es correcto mostrar un valor almacenado en caché en función de una marca de tiempo.

Nota: Las directivas max-age y s-maxage del encabezado Cache-Control tienen prioridad sobre el encabezado Expires y lo anulan. Para obtener más información, consulta “Configura el vencimiento de las entradas en caché” y <UseResponseCacheHeaders> en la política de caché de respuesta.

Los formatos de fecha aceptables para el encabezado Expires se describen en la especificación HTTP/1.1. Por ejemplo:

Vencimiento: martes 01 de diciembre de 1994 16:00:00 GMT

Para obtener información detallada sobre los formatos de fecha y hora HTTP, consulta Formatos de fecha y hora en la especificación HTTP/1.1.

Nota: Si bien en la sección 14.21 de la especificación se indica que un valor Expires de más de un año en el futuro significa que una entrada de caché nunca vence, Apigee interpreta que tal valor significa que la entrada debe almacenarse en caché hasta la fecha y lahora especificadas.

Para obtener más información sobre el encabezado Expires, consulta las Definiciones de los campos del encabezado en la especificación HTTP/1.1.

ETag

Una etiqueta de entidad (ETag) es un identificador asociado con un recurso solicitado. Mediante el uso de una ETag, un servidor puede determinar si el recurso solicitado y el recurso asociado almacenado en caché coinciden. Por ejemplo, el servidor puede volver a almacenar en caché la respuesta si no coincide con la que está almacenada en caché actualmente. Podría mostrar el recurso almacenado en caché si las ETags coinciden.

Cuando un extremo de destino envía una respuesta a Edge con una ETag, Edge almacena en caché la ETag junto con la respuesta.

Puedes obtener más información sobre las etiquetas de entidad en los parámetros del protocolo de la especificación HTTP/1.1.

If-Match

Con el encabezado de la solicitud If-Match, una entidad almacenada en caché es actual si la ETag del encabezado coincide con la ETag almacenadaen caché. Cualquier solicitud distinta de GET que especifique un encabezado If-Match se pasa al servidor de origen para garantizar que cualquier instalación de almacenamiento en caché de origen tenga la oportunidad de procesar la solicitud.

Puedes obtener más información sobre If-Match en las definiciones de los campos del encabezado en la especificación HTTP/1.1.

Si Edge recibe una solicitud GET entrante de un cliente que incluye un encabezado If-Match, sucede lo siguiente:

If	Entonces
El encabezado `If-Match` especifica una o más ETags.	Apigee Edge recupera las entradas de caché que no estén vencidas del recurso especificado y compara las ETags sólidas de esas entradas almacenadas en caché con las especificadas en el encabezado `If-Match`. Si se encuentra una coincidencia, se muestra la entrada de caché. De lo contrario, la solicitud se pasa al servidor de origen.
El encabezado `If-Match` especifica “*”.	La solicitud se pasa al servidor de origen para garantizar que cualquier instalación de almacenamiento en caché de origen tenga la oportunidad de procesar la solicitud.
Se encontró una entrada de caché con el mismo URI de solicitud, pero solo contiene ETags débiles.	El servidor de origen debe volver a validar la entrada antes de que se la muestre al cliente.
Las ETags provienen del servidor de origen.	La ETag se muestra sin cambios al cliente.

If-None-Match

Con el encabezado If-None-Match, una entidad almacenada en caché es actual si la ETag del encabezado no coincide con la ETag almacenadaen caché. Las solicitudes distintas de GET que contienen este encabezado se pasan al servidor de origen.

Si Edge recibe una solicitud GET entrante con este encabezado, sucede lo siguiente:

If	Entonces
El encabezado `If-None-Match` especifica una o más ETags.	Apigee Edge recupera las entradas de caché que no estén vencidas del URI especificado y compara las ETags sólidas de esas entradas almacenadas en caché con las especificadas en el encabezado `If-None-Match`. Si se encuentra una coincidencia, Edge muestra un estado 304 Sin modificar. Si no se encuentra ninguna coincidencia, Edge pasa la solicitud al servidor de origen.
El encabezado `If-None-Match` especifica “*” y existe una entrada almacenada en caché que no está vencida para el URI solicitado.	Edge muestra un estado 304 Sin modificar.
Se encontró una entrada de caché con el mismo URI de solicitud, pero solo contiene ETags débiles.	El servidor de origen debe volver a validar la entrada antes de que Edge se la muestre al cliente.
Edge recibe una ETag de un servidor de origen.	La ETag se muestra sin cambios al cliente.

If-Modified-Since

Si Apigee Edge recibe un encabezado If-Modified-Since en una solicitud GET, se pasa al servidor de origen, incluso si existe una entrada de caché válida.

Esto garantiza que se tengan en cuenta las actualizaciones de un recurso que no pasaron a través de Apigee Edge. Si el servidor de origen muestra una entidad nueva, Edge reemplazará la entrada de caché existente por el valor nuevo. Si el servidor muestra un estado 304 Sin modificar, Edge muestra el valor de respuesta si el encabezado Last-Modified de la respuesta almacenada en caché indica que no cambió.

Accept-Encoding

Cuando en una solicitud entrante se incluye el encabezado Accept-Encoding con valores de gzip, deflate o compress, el servidor de origen responde con datos comprimidos. Cuando las solicitudes posteriores llegan sin los encabezados Accept-Encoding, esperan una respuesta sin comprimir. El mecanismo de almacenamiento en caché de respuestas de Apigee es capaz de enviar respuestas comprimidas y sin comprimir, en función de los encabezados entrantes sin volver al servidor de origen.

Puedes hacer que los valores del encabezado de aceptación se agreguen a las claves de caché con el fin de hacer que las claves sean más significativas para cada elemento almacenado en caché. Para obtener más detalles, consulta "Configura una clave de caché" en la Política de caché de respuesta.