Show all posts by user
Discussions in German
> Т.е вы утверждаете, что значения переменой $proxy_host в данном
> запросе будет = apple-shop.com, а не samsung-shop.com?
> Сейчас проверить самостоятельно не могу, потому что везде у нас
> FastCGI.
Вы правы, $proxy_host = proxy_pass, я со своим FastCGI у
by
S.A.N
-
Nginx Mailing List - Russian
Хочу уточнить, я не предлагаю полную аналогию с UseCanonicalName, я имел виду использовать значения переменной $host, при условии что host из absoluteURI отличается от значения клиентского заголовка Host.
by
S.A.N
-
Nginx Mailing List - Russian
> Коллизии возможны только в одном случае: программист не проверяет
> данные,
> получаемые от клиента, и такому программисту никаким костылями не
> поможешь.
Проверять на бекенде значения Host не рационально, если
by
S.A.N
-
Nginx Mailing List - Russian
> Ровным счетом так nginx и поступает, если передан absoluteURI, то
> виртуальный
> сервер определяется по нему, а заголовок Host игнорируется.
Ровным счетом так же должен поступать и бекенд, игнорировать заголовок Host, если
by
S.A.N
-
Nginx Mailing List - Russian
> 0 строчек кода - это невозможно.
Все возможно, я выше писал, как я решил эту проблему.
В конфиге по прежнему для работы с клиент кешем, установлена передача все нужных заголовком.
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
by
S.A.N
-
Nginx Mailing List - Russian
> Чем такой простой и удобный вариант Вам не подходит, я не понимаю.
Дело в том что я ленивый перфекционист, не люблю писать лишний код :)
X-Accel-Expires рабочий вариант и он подходит, просто я не уверен что это идеал вариант,
by
S.A.N
-
Nginx Mailing List - Russian
Gena Makhomed Wrote:
-------------------------------------------------------
> возможно имеет смысл дефолтовые настройки сделать такими,
> чтобы они были безопасными по-умолчанию для всех пользователей?
> т.е. $host вместо $proxy_host ?
Поддержу данную мы
by
S.A.N
-
Nginx Mailing List - Russian
> А зачем использовать куку? Почему нельзя просто прописать:
>
> fastcgi_no_cache $upstream_http_etag;
> fastcgi_cache_bypass $http_if_none_match;
>
> Ведь для public кеша, насколько я понял, ETag не отдается.
Для public кеш, ETag отдается.
Это сделано на пе
by
S.A.N
-
Nginx Mailing List - Russian
> Кстати, похоже, что есть вариант еще проще, используя директиву
> fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match
> и выставляя в ответе заголовок X-Accel-Expires: 0
> если статус ответа backend`а будет 304.
Да, у меня крутился в
by
S.A.N
-
Nginx Mailing List - Russian
> Торг здесь не уместен. Можно написать статью и без ревалидации по
> ETag.
>
> Как реализовать ревалидацию по ETag, если его просто не будет у части
> клиентов. В кеше ведь всегда находится только один вариант контен
by
S.A.N
-
Nginx Mailing List - Russian
> >> Отдает контент с заголовками
> >> Cache-Control: private, max-age=0
>
> если было бы "Cache-Control: private", вроде как было бы то же самое,
> нет ? на 10 символов короче.
Можно не указывать max-age=0, по спецификации если не указа
by
S.A.N
-
Nginx Mailing List - Russian
> так что Ваш вариант
>
> fastcgi_cache_methods GET HEAD;
> fastcgi_cache_key "$host$uri$is_args$args";
>
> не оптимален, включает $uri$is_args$args вместо $request_uri
> и даже ошибочен, потому что не включает в себя $request_method.
HEAD кэширует ответ с тело
by
S.A.N
-
Nginx Mailing List - Russian
> перечитал RFC, к числу hop-by-hop хедеров они не относятся,
> получается, их надо всегда передавать на бекенд?
Да, эти заголовков при прозрачном проксировании передаются без изменений, к сожалению Nginx самостоятельно уда
by
S.A.N
-
Nginx Mailing List - Russian
> передавать на backend заголовки If-Modified-Since и If-None-Match
> или нет - это тоже можно настроить по разному для разных location`ов.
Да, согласен, но этот вариант очень не хочется реализовывать, довольно большой перечень location приде
by
S.A.N
-
Nginx Mailing List - Russian
> > fastcgi_cache_key "$host$uri$is_args$args";
>
> Это ни разу ни баг - это вы недонастроили.
>
> Добавьте в ключ кеширования параметр
> $http_if_modified_since
> и наступит вам счастье.
Я наверно не доступно объяснию суть проблем
by
S.A.N
-
Nginx Mailing List - Russian
> О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в
> кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому,
> что специально разрешили кешировать 304).
>
> А как ведет себя fastcgi_cache_valid 0s
Вот к
by
S.A.N
-
Nginx Mailing List - Russian
> Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно -
> параметры, от которых зависит или может зависеть ответ бекенда,
> должны быть включены в ключ кеша.
Я не понимаю, как добавления в ключ кеша хедера if_
by
S.A.N
-
Nginx Mailing List - Russian
> А какого рода динамический контент, можете привести пример? Желательно
> с
> примером, когда помогает ревалидация.
Например, блоги наших клиентов, есть открытые публичные блоги есть закрытые приватные, в каждом
by
S.A.N
-
Nginx Mailing List - Russian
> > Есть более красивые решения этой проблемы?
> А в чем, собственно, состоит проблема?
>
> Я вот даже не могу понять - если вы все равно пропускаете все запросы
> на бекенд для ревалидации по e-tag - зачем у вас включ
by
S.A.N
-
Nginx Mailing List - Russian
> а расскажите, о каких ресурсах идет речь ?
> если это js/css/картинка, ее всегда можно переименовать с хешем и
> добавить Cache-Control: max-age=очень-много
Речь идет, о динамическом контенте, бекенд на РНР.
Насчёт статичного к
by
S.A.N
-
Nginx Mailing List - Russian
> Теперь все работает правильно, при клиент кешировании, мы в заголовок
> Cache-Control пишем дерективу private, это запретит Nginx кешировать
> данный ответ и таким образом он не попадет в кеш не при 200 статусе и
> так же ответ
by
S.A.N
-
Nginx Mailing List - Russian
> И если отдать 304 на основании значения If-None-Match, то в кеше
> nginx'а будет оставлен потенциально устаревший ответ. Т.е.
> If-None-Match нужно просто убрать из рассмотрения при генерации
> ответа на бекенде, иначе корректн
by
S.A.N
-
Nginx Mailing List - Russian
> Если вы хотите, чтобы оно работало так, то надо включить в ключ
> кеширования заголовок If-None-Match - т.к. от него зависит ответ
> бекенда.
Нет, так делать не надо, потому что на один uri может быть только один актуальный
by
S.A.N
-
Nginx Mailing List - Russian
> поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции
> заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее
> включать/выключать
> http://nginx.org/en/docs/http/ngx_http_core_module.html#etag
>
> Не забывайте, что еще есть разница м
by
S.A.N
-
Nginx Mailing List - Russian
В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по нему ревалидировать.
По идеи это временное решения, когда Nginx сделает поддержку ETag
by
S.A.N
-
Nginx Mailing List - Russian
> Если файла в кеше нет - то откуда взялся ответ 304?
Ответ 304 появился, потому что клиент прислал HTTP_IF_NONE_MATCH, т.е ревалидация была произведена по Etag, в нашем конфиге Nginx есть строка
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
он
by
S.A.N
-
Nginx Mailing List - Russian
Заметили очень неприятный баг, в результате которого, клиенты получали пустую страницу.
Конфиг кеширования:
fastcgi_cache_path cache levels=1:2 keys_zone=cache:256m inactive=1d;
fastcgi_cache cache;
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_methods GET HEAD;
fastcgi_cache
by
S.A.N
-
Nginx Mailing List - Russian
Вам правильно ответили, в первую очередь нужно читать документацию.
Возможно вы удивитесь но ваш конфиг по кешированию может и должен выглядить намного короче, как-то так
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_methods GET HEA
by
S.A.N
-
Nginx Mailing List - Russian