6 votos

RFC 2616 con Apache 2.4

Estoy usando Apache 2.4.3 como un proxy inverso debido a que es anunciado el cumplimiento con el RFC 2616. Mi aplicación usa encabezados como este para habilitar el almacenamiento en caché del proxy:

Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: A
Vary: X-Group
ETag: W/"foo1"

Después de la primera solicitud se calienta la caché, si mi aplicación de los cambios a responder con esto:

Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: B
Vary: X-Group
ETag: W/"foo2"

La aplicación va a responder con 304 No Modificado si el If-None-Match encabezado de Apache coincide con el origen generado ETag. Sin embargo, Apache, a continuación, se almacena en caché la segunda respuesta 200 y reemplaza a la "foo1" registro con la nueva respuesta en lugar de almacenamiento en caché, tanto de las respuestas con diferentes ETags. Por lo tanto, en lugar de If-None-Match: W/"foo1", W/"foo2" el próximo revalidar solicitud es justo If-None-Match: W/"foo2". Así que la caché está recibiendo constantemente pierde en vez de conseguir siempre hits.

Desde el RFC 2616 sección 12.1:

Sin embargo, un servidor de origen no está limitado a estas dimensiones y PUEDE variar la respuesta basada en cualquier aspecto de la solicitud, incluyendo información fuera de la solicitud de los campos de encabezado o dentro de la extensión de los campos de encabezado no definidos en la presente especificación.

He probado las siguientes combinaciones para Variar:

Vary: X-Foo
Vary: *
Vary: User-Agent

También he intentado tanto, el fuerte y el débil ETags y no importa lo que no puedo conseguir Apache para almacenar en caché los dos respuestas al mismo tiempo, que siempre guarda sobre el anterior. Si no puede guardar más de una varianza de una página, a continuación, ETag es inútil, de Última Modificación sería igual de bueno.

Desde el Apache 2.4 docs:

mod_cache implementa un RFC 2616 compatible con HTTP contenido de la caché de filtro, con soporte para el almacenamiento en caché de contenido negociado respuestas que contiene el encabezado Vary.

Nota que dice "respuestas" en plural. Estoy mal interpretando el HTTP spec o Apache 2.4 simplemente no totalmente compatible con ETags después de todo?

1voto

Vortura Puntos 270

Te damos un par de ejemplos como este:

Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: A
Vary: X-Group
ETag: W/"foo1"

Me doy cuenta, en particular, la Vary: X-Group de encabezado. Es X-Group un encabezado de solicitud o un encabezado de respuesta?

Según el RFC 2616 sección 14.44, Vary debe ser una lista de cualquier solicitud de encabezados que dará como resultado un contenido diferente de la representación de un servidor de origen. A partir de su ejemplo, sospecho X-Group podría ser un encabezado de respuesta, en cuyo caso mod_cache no almacenar múltiples versiones de un recurso dado.

Una cosa que usted podría intentar, sería establecer Vary: If-None-Match, lo que permitiría a mod_cache almacenar una versión de los recursos para cada uno de ETag. Sin duda, yo no he probado esto. Suponiendo que funciona, una desventaja es que la primera petición de cualquier cliente podría ser un error de caché.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: