cache caching symfony cache-control http-caching

caching - symfony cache



¿Está bien si la primera respuesta es privada con AppCache(Symfony2)? (2)

El comportamiento que experimentas es intencionado. Los documentos de Symfony2 describen explícitamente las situaciones en las que se utiliza el público y el público , siendo el valor predeterminado privado .

Estoy tratando de usar el almacenamiento en caché de http. En mi controlador estoy configurando una respuesta de la siguiente manera:

$response->setPublic(); $response->setMaxAge(120); $response->setSharedMaxAge(120); $response->setLastModified($lastModifiedAt);

modo dev

En el entorno de desarrollo, la primera respuesta es un 200 con los siguientes encabezados:

cache-control:max-age=120, public, s-maxage=120 last-modified:Wed, 29 Feb 2012 19:00:00 GMT

Durante los próximos 2 minutos, cada respuesta es un 304 con los siguientes encabezados:

cache-control:max-age=120, public, s-maxage=120

Esto es básicamente lo que espero que sea.

modo prod

En el modo prod, los encabezados de respuesta son diferentes. Tenga en cuenta que en app.php envuelvo el kernel en AppCache.

La primera respuesta es un 200 con los siguientes encabezados:

cache-control:must-revalidate, no-cache, private last-modified:Thu, 01 Mar 2012 11:17:35 GMT

Entonces es una respuesta privada sin caché.

Cada próxima solicitud es más o menos lo que yo esperaba; un 304 con los siguientes encabezados:

cache-control:max-age=120, public, s-maxage=120

¿Debería preocuparme por eso? ¿Es un comportamiento esperado?

¿Qué pasará si coloco el servidor Varnish o Akamai frente a él?

Hice un poco de depuración y calculé que la respuesta es privada debido al encabezado modificado por última vez. HttpCache kernel usa EsiResponseCacheStrategy para actualizar la respuesta en caché ( HttpCache::handle() ).

if (HttpKernelInterface::MASTER_REQUEST === $type) { $this->esiCacheStrategy->update($response); }

EsiResponseCacheStrategy convierte una respuesta en no cacheable si utiliza Last-Response o ETag ( EsiResponseCacheStrategy::add() ):

if ($response->isValidateable()) { $this->cacheable = false; } else { // ... }

Response::isValidateable() devuelve verdadero si está presente el encabezado Last-Response o ETag.

Resulta en sobrescribir el encabezado Cache-Control ( EsiResponseCacheStrategy::update() ):

if (!$this->cacheable) { $response->headers->set(''Cache-Control'', ''no-cache, must-revalidate''); return; }

Hice esta pregunta en el grupo de usuarios de Symfony2 pero hasta ahora no obtuve una respuesta: https://groups.google.com/d/topic/symfony2/6lpln11POq8/discussion

Actualizar.

Como ya no tengo acceso al código original, traté de reproducir el escenario con la última edición estándar de Symfony .

Los encabezados de respuesta son más consistentes ahora, pero aún parecen estar equivocados.

Tan pronto como configuro un encabezado Last-Modified en la respuesta, la primera respuesta hecha por un navegador tiene:

Cache-Control:must-revalidate, no-cache, private

La segunda respuesta tiene una expectativa:

Cache-Control:max-age=120, public, s-maxage=120

Si evito enviar el encabezado If-Modified-Since , cada solicitud devuelve must-revalidate, no-cache, private .

No importa si la solicitud se realizó en el entorno prod o dev .


Me he enfrentado el mismo problema. Tuve que proporcionar encabezados ''públicos'' mi CDN. De forma predeterminada, cuando el almacenamiento en caché de la puerta de enlace está habilitado en el modo prod, se devuelve 200 OK con privado, nocache debe validar los encabezados.

Resolví el problema de esta manera.

En app.php, antes de enviar una respuesta al usuario ($ responder-> enviar), he sobrescrito el encabezado del control de caché para ponerlo en blanco y establecer los encabezados de caché en público y la antigüedad máxima (algún valor).

// fragmento de código de app.php

$response = $kernel->handle($request); $response->headers->set(''Cache-Control'', ''''); $response->setPublic(); $response->setMaxAge(86400); $response->send();