Esta página se ha traducido con Cloud Translation API.

Compatibilidad con encabezados de respuesta HTTP

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

En este tema se describe cómo gestiona Apigee los encabezados de almacenamiento en caché HTTP/1.1 cuando se usa la política ResponseCache. Actualmente, Apigee admite un subconjunto de los encabezados y las directivas de almacenamiento en caché de HTTP/1.1 (las funciones no admitidas se indican en este tema) recibidos de los servidores de destino (origen) backend.

Además, con determinados encabezados, Apigee toma medidas en función de sus directivas. En algunos casos, estos encabezados de caché HTTP/1.1 anulan el comportamiento especificado en la política ResponseCache. Por ejemplo, si un servidor backend devuelve el encabezado Cache-Control, puedes hacer que la directiva s-maxage del encabezado anule potencialmente otros ajustes de vencimiento de la política.

Nota: Uso de encabezados para influir en las claves de caché y en el TTL de las entradas de caché Puedes hacer que Apigee use los encabezados de respuesta al crear claves de caché de respuesta y al definir el TTL de las entradas de caché. Para ello, usa estos elementos de marca de la política ResponseCache:

<UseResponseCacheHeaders>: si se define en true, Apigee tendrá en cuenta los encabezados de respuesta HTTP que se usen al definir el tiempo de vida (TTL) de la respuesta en la caché. Para obtener más información, consulta "Configurar la caducidad de las entradas de caché" y <UseResponseCacheHeaders> en Política de caché de respuestas.
<UseAcceptHeader>: si se define como true, Apigee usará los encabezados de respuesta Accept para aumentar la clave de caché. Para obtener más información, consulta <UseAcceptHeader> en Política de caché de respuestas.

Header	Asistencia
Cache-Control	Se admite en las respuestas devueltas por los servidores de origen backend, pero no en las solicitudes de clientes. Apigee admite un subconjunto de directivas.
Caducidad	Compatible. Se puede anular.
Etiquetas de entidad (ETags)	Comportamiento específico de If-Match y If-None-Match.
If-Modified-Since	En las solicitudes GET, el encabezado se envía al servidor de origen aunque exista una entrada de caché válida.
Accept-Encoding	Apigee envía respuestas comprimidas o sin comprimir en función de los encabezados entrantes.

Control de caché

Apigee solo admite el encabezado Cache-Control en las respuestas devueltas por los servidores de origen backend (la especificación HTTP/1.1 permite encabezados Cache-Control tanto en las solicitudes de cliente como en las respuestas de servidor de origen). Los servidores de origen pueden incluir tanto los endpoints de destino definidos en un proxy de API de Apigee como los creados mediante llamadas a la API TargetServer.

Limitaciones de la compatibilidad con Cache-Control

Apigee admite un subconjunto de Cache-Controlfunciones de encabezado de respuesta definidas en la especificación HTTP/1.1. Ten en cuenta lo siguiente:

Apigee no admite encabezados Cache-Control que lleguen con solicitudes de clientes entrantes.
Apigee solo admite el concepto de cachés públicas. Según la especificación HTTP, Cache-Control puede ser público (compartido) o privado (de un solo usuario).
Apigee solo admite un subconjunto de directivas de respuesta Cache-Control en la especificación HTTP/1.1. Consulta Compatibilidad con las directivas del encabezado de respuesta Cache-Control para obtener más información.

Compatibilidad con directivas de encabezado de respuesta Cache-Control

Apigee admite un subconjunto de directivas 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 con las directivas del encabezado de respuesta Cache-Control de HTTP.

Para obtener información más detallada sobre las directivas que se indican aquí, consulta Cache-Control en la especificación HTTP/1.1.

Directiva Cache-Control	Cómo procesa Apigee la directiva
`cache-extension`	No es compatible.
`max-age`	Si la política ResponseCache define el elemento `<UseResponseCacheHeaders>` como `true`, la respuesta se puede almacenar en caché durante el número de segundos especificado por esta directiva. Esta directiva se anula con la directiva `s-maxage` y anula el encabezado `Expires`. También se puede anular con el elemento `<ExpirySettings>` de la política. Para obtener más información, consulta "Configurar la caducidad de las entradas de caché" y `<UseResponseCacheHeaders>` en Política de caché de respuestas. Nota: El contenido almacenado en caché con la política ResponseCache conservará el valor max-age definido por su origen. Esto significa que, cuando se recupera de la caché, el contenido puede ser más antiguo de lo que sugiere su valor max-age (más antiguo de lo que sabe el cliente).
`must-revalidate`	No es compatible. Apigee elimina todas las entradas de caché en cuanto caducan.
`no-cache`	Apigee almacena en caché la respuesta del origen, pero debe volver a validarse con el servidor de origen antes de usarse para satisfacer cualquier solicitud de cliente posterior. Esta regla permite que el origen devuelva una respuesta 304 Not Modified para indicar que la respuesta debe devolverse desde la caché, lo que ahorra el procesamiento necesario para devolver la respuesta completa. Si el servidor de origen devuelve una respuesta completa, sustituye la entrada de caché. Se ignorarán los nombres de campo que se especifiquen con esta directiva. Nota: El encabezado HTTP/1.0, `Pragma: no-cache`, se trata como equivalente a `Cache-Control: no-cache`.
`no-store`	No es compatible.
`no-transform`	No es compatible.
`private`	No es compatible. Si se recibe esta directiva, la respuesta del origen no se almacena en caché. Se ignoran los nombres de los campos.
`proxy-revalidate`	No es compatible. Apigee elimina todas las entradas de caché en cuanto caducan.
`public`	Apigee almacena en caché la respuesta del origen, aunque otras directivas indiquen lo contrario. Según la especificación de HTTP/1.1, la única excepción a esta regla es si la respuesta incluye un encabezado Authorization.
`s-maxage`	Si la política ResponseCache define el elemento `<UseResponseCacheHeaders>` como `true`, la respuesta se puede almacenar en caché durante el número de segundos especificado por esta directiva. Esta directiva anula la directiva `max-age` y el encabezado `Expires`. Se puede anular con el elemento `<ExpirySettings>` de la política. Para obtener más información, consulta "Configurar la caducidad de las entradas de caché" y `<UseResponseCacheHeaders>` en Política de caché de respuestas. Nota: El contenido almacenado en caché con la política ResponseCache conservará el valor s-maxage definido por su origen. Esto significa que, cuando se recupera de la caché, el contenido puede ser más antiguo de lo que sugiere su valor s-maxage (más antiguo de lo que sabe el cliente).

Caducidad

Cuando la marca UseResponseCacheHeaders de la política ResponseCache se define como true, Apigee puede usar el encabezado Expires para determinar el tiempo de vida (TTL) de una entrada almacenada en caché. Este encabezado especifica una fecha y hora a partir de las cuales se considera que la entrada de caché de una respuesta está obsoleta. Este encabezado permite a los servidores indicar cuándo se puede devolver un valor almacenado en caché en función de una marca de tiempo.

Nota: Las directivas de encabezado Cache-Control max-age y s-maxage tienen prioridad sobre el encabezado Expires y lo anulan. Para obtener más información, consulta "Definir la caducidad de las entradas de caché" y <UseResponseCacheHeaders> en Política de caché de respuestas.

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

Fecha de vencimiento: Jue, 01 de dic de 1994 16:00:00 GMT

Para obtener información detallada sobre los formatos de fecha y hora HTTP, consulta la sección Date/Time Formats (Formatos de fecha y hora) de la especificación HTTP/1.1.

Nota: Aunque la sección 14.21 de la especificación indica que un valor de Expires de más de un año en el futuro significa que una entrada de caché nunca caduca, Apigee interpreta que ese valor significa que la entrada debe almacenarse en caché hasta la fecha y la hora especificadas.

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

ETag

Una etiqueta de entidad (ETag) es un identificador asociado a un recurso solicitado. Con una ETag, un servidor puede determinar si el recurso solicitado y el recurso almacenado en caché asociado coinciden. Por ejemplo, el servidor podría volver a almacenar en caché la respuesta si no coincide con lo que está almacenado en caché. Podría devolver el recurso almacenado en caché si las etiquetas ETag coinciden.

Cuando un endpoint de destino envía una respuesta a Apigee con un ETag, Apigee almacena en caché el ETag junto con la respuesta.

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

If-Match

Con el encabezado de solicitud If-Match, una entidad almacenada en caché está actualizada si el ETag del encabezado coincide con el ETag almacenado en caché. Las solicitudes que no sean GET y que especifiquen un encabezado If-Match se transfieren al servidor de origen para asegurarse de que las instalaciones de almacenamiento en caché de origen tengan la oportunidad de procesar la solicitud.

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

Si Apigee recibe una solicitud GET entrante de un cliente que incluye un encabezado If-Match:

Si	Entonces
El encabezado `If-Match` especifica uno o varios ETags.	Apigee recupera las entradas de caché no caducadas del recurso especificado y compara las etiquetas ETag sólidas de esas entradas en caché con las especificadas en el encabezado `If-Match`. Si se encuentra una coincidencia, se devuelve la entrada de la caché. Si no es así, la solicitud se envía al servidor de origen.
El encabezado `If-Match` especifica "*"	La solicitud se reenvía al servidor de origen para asegurarse de que cualquier instalación de almacenamiento en caché de origen tenga la oportunidad de procesar la solicitud.
Se ha encontrado 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 devolverla al cliente.
Las etiquetas ETag proceden del servidor de origen.	El ETag se devuelve sin cambios al cliente.

If-None-Match

Con el encabezado If-None-Match, una entidad almacenada en caché está actualizada si el ETag del encabezado no coincide con el ETag almacenado en caché. Las solicitudes que no sean GET y que contengan este encabezado se envían al servidor de origen.

Si Apigee recibe una solicitud GET entrante con este encabezado:

Si	Entonces
El encabezado `If-None-Match` especifica uno o varios ETags.	Apigee recupera las entradas de caché no caducadas del URI especificado y compara las etiquetas ETag sólidas de esas entradas en caché con las especificadas en el encabezado `If-None-Match`. Si se encuentra una coincidencia, Apigee devuelve el estado 304 Not Modified. Si no se encuentra ninguna coincidencia, Apigee envía la solicitud al servidor de origen.
La cabecera `If-None-Match` especifica "*" y existe una entrada en caché no caducada para el URI solicitado.	Apigee devuelve el estado 304 Not Modified
Se ha encontrado 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 Apigee la devuelva al cliente.
Apigee recibe un ETag de un servidor de origen	El ETag se devuelve sin cambios al cliente.

If-Modified-Since

Si Apigee recibe un encabezado If-Modified-Since en una solicitud GET, se envía al servidor de origen aunque exista una entrada de caché válida.

De esta forma, se tienen en cuenta las actualizaciones de un recurso que no ha pasado por Apigee. Si el servidor de origen devuelve una entidad nueva, Apigee sustituye la entrada de caché existente por el nuevo valor. Si el servidor devuelve el estado 304 Not Modified, Apigee devuelve el valor de la respuesta si el encabezado Last-Modified de la respuesta almacenada en caché indica que no ha cambiado.

Accept-Encoding

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

Puedes añadir valores de encabezado Accept a las claves de caché para que sean más significativas para cada elemento almacenado en caché. Para obtener más información, consulta "Configurar una clave de caché" en la política de caché de respuestas.