Symfony 3.4 http-кеш, всегда Cache-Control: max-age = 0, необходимо перепроверить, частный
Пробую в аннотации
* @Cache(expires = "+10 hours", public=false)
или в контроллере
$maxAge = 60*60;
$response->setExpires(Carbon::create()->addHour());
$response->setSharedMaxAge($maxAge);
$response->setPublic();
$response->setMaxAge($maxAge);
И еще есть Cache-Control: max-age=0, must-revalidate, private
Сеансы использования приложения, пользователь входит в систему - я хочу - кеш закрыт, но ничего не работает - я всегда получаю это.
Я добавил FOS\HttpCacheBundle\FOSHttpCacheBundle()
(просто добавьте) Надеюсь, что он переопределит кеш Symfony и разрешит частную отправку кеша - но ничего не изменится.
Ответы 3
Вы используете обратный прокси, такой как Symfony? https://symfony.com/doc/3.4/http_cache.html#symfony-reverse-proxy
Кроме того, в вашем примере у аннотации public = false, а у контроллера public true.
Другая возможная проблема может заключаться в том, что ваш веб-сервер (Apatche и т. д.) Настроен на добавление этого заголовка или параметр в вашем файле .htaccess указывает это.
Такое поведение является новым в Symfony 3.4 и 4.0. Если сеанс пользователя был инициализирован, он всегда будет устанавливать заголовки, как описано в вашем вопросе.
Представленный в Symfony 4.1, вы можете переопределить это поведение. Однако, поскольку это новая функция, она не будет перенесена в Symfony 3.4.
$response->headers->set(AbstractSessionListener::NO_AUTO_CACHE_CONTROL_HEADER, 'true');
Вы можете прочитать об этом в документации Symfony: Кэширование HTTP и пользовательские сеансы
Видимо, вы правильно читаете. Это нетривиальный перерыв B / C для настроек на основе ESI, можно даже не кэшировать ответы, которые не зависят от пользователя, когда существует cookie сеанса (независимо от фактического состояния входа в систему). Отчет об ошибке: github.com/symfony/symfony/issues/29151
Вероятно, лучший способ сделать это - использовать Украшение сервиза, но пока я предпочел грязный путь.
В моем случае мне просто нужны были общие кешированные заголовки для конкретного контроллера.
Workaroung для Symfony 3.4. *:
Создайте прослушиватель с более низким приоритетом, чем Symfony\Component\HttpKernel\EventListener\SessionListener в services.yml (не знаю, рекомендуется ли это):
AppBundle\Listener\ResponseListener:
tags:
- { name: kernel.event_listener, event: kernel.response, priority: -1001 }
Затем в AppBundle\Listener\ResponseListener:
<?php
namespace AppBundle\Listener;
use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
class ResponseListener
{
public function onKernelResponse(FilterResponseEvent $event)
{
$response = $event->getResponse();
$controller = $event->getRequest()->attributes->get('_controller');
$requiredAssetAction = "AppBundle\Controller\Website\AssetsController::assetAction";
if ($controller == $requiredAssetAction) {
$response->headers->addCacheControlDirective('max-age', 900);
$response->headers->addCacheControlDirective('s-maxage', 900);
$response->headers->addCacheControlDirective('must-revalidate', true);
$response->headers->addCacheControlDirective('public', true);
$response->headers->removeCacheControlDirective('private');
}
$event->setResponse($response);
}
}
Я читаю это неправильно, или это означает, что в v3.4 невозможно использовать ESI с HTTP-кешем, если у вас есть активный пользовательский сеанс?