Добавить переменую $cache status

2013-11-14 Пенетрантность S.A.N
Для инвалидации кеша, мы планировали использовать такую схему: fastcgi_cache_valid 200 … 1s; fastcgi_cache_use_stale error updating http_503; По истечения 1 секунды, запрос будет идти на бекенд, на котором РНР скрипт определяет изменились данные в БД которые использовались в данном URI с момента

Re: Добавить переменую $cache status

2013-11-14 Пенетрантность S.A.N
Нашел :) Переменная есть - $upstream_cache_status; Но будет, интересно услышать идеи как можно улучшить данную схему кеширования . Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244684#msg-244684 ___ nginx-ru mailing list

Re: Добавить переменую $cache status

2013-11-15 Пенетрантность S.A.N
Можно где-то подробней почитать, про новые возможности для инвалидации кеша? If-Modified-Since - работает по дате, это хорошо, но для полноты возможностей, нужна поддержка ETag, но все равно спасибо вам, приятно видеть что идет прогресс в этом направлении. Posted at Nginx Forum:

Re: Добавить переменую $cache status

2013-11-15 Пенетрантность S.A.N
Отличия ETag от Last-Modified, в формате значений, в ETag произвольный формат и многие разработчики это используют для передачи хеш состояний ответа, некоторые даже используют значения ETag для передачи серелизированой строки в которой хранится состояния ответа. Это удобный и гибкий способ,

Re: Добавить переменую $cache status

2013-11-18 Пенетрантность S.A.N
Если в нашей дискуссии есть практический смысл (реализация Etag в ближайших версия). Я могу много рассказать про невозможность использовать Last-Modified для ревалидации. Реальный пример из жизни, у нас есть страница товара, ниже выводим комментарии пользователей, хедер страницы Last-Modified –

Re: Добавить переменую $cache status

2013-11-18 Пенетрантность S.A.N
Проблем с HTTP/1.0 не будет в принципе, бекенд не работает на прямую с клиентом по HTTP/1.0, бекенд работает с Nginx, который в свою очередь должен передать HTTP_IF_NONE_MATCH взятым из файла кеша Nginx, бекенд проведет ревалидацию и ответит 304 или 200 с контентом страницы, клиент получит ответ

Cache Revalidate

2013-11-26 Пенетрантность S.A.N
Есть досадные мелочи, которые хотелось бы исправить, при включении fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда отправляется на сервер, даже если кеша нет, бекенду будет отправлен параметр с пустым значением. По стандартам HTTP при отсутствии кеша, клиент не должен

Re: Cache Revalidate

2013-11-27 Пенетрантность S.A.N
А use case какой? С учётом характерных времён доступа по http - запрет кеширования даже на 1 секунду выглядит странно. Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить, это нормальная

Re: Cache Revalidate

2013-11-27 Пенетрантность S.A.N
use case и о происхождении требования о недопустимости кеширования даже на 1 секунду. Возможно, это позволило бы пересмотреть существующее поведение при max-age=0, благо в Cache-Control есть и другие способы запрета кеширования. use case продиктован нашей бизнес логикой, мы кешируем все

Re: Cache Revalidate

2013-11-27 Пенетрантность S.A.N
Уточнения, там где контент совсем статичный мы кешируем его на долго без ревалидации. Постоянная ревалидация нам нужна только на динамичном контенте, все написанное выше имеет отношения только к динамичному контенту. Posted at Nginx Forum:

Re: Cache Revalidate

2013-11-28 Пенетрантность S.A.N
- Добавлять комментарий без перезагрузки страницы javascript'ом, отправлять на сервер - через ajax. Так, насколько я понимаю, сейчас делают чуть менее, чем все, в том числе упоминаемый вами же facebook. Я же написал, что мы знаем как можно работать с задержками, но зачем это всё

Re: Cache Revalidate

2013-11-28 Пенетрантность S.A.N
Извините что вклиниваюсь, но это полная победа разума над логикой. А идти вразрез с логикой правильно только в алгоритмах защиты, дабы спутать врага. Я же не настаиваю на этом решении, это уже вам решать. Если интересно как юзается max-age=0 для кеширования, далеко ходить не надо, Google в

Re: Cache Revalidate

2013-11-28 Пенетрантность S.A.N
Роман Москвитин Wrote: --- Кому как, мне вот только что ответил двухсоткой. Несколько раз. Различный контент пошел уже с 304, но там и max-age далеко не ноль. Про использование кук и прочих ETag я ничего не говорил, но кеширование при

Re: Как удержать проксирование в пределах поддиректории сайта (proxy redirect не срабатывает) ?

2013-12-04 Пенетрантность S.A.N
SEO по общему использованию кукисов на двух разных бакэндах при общем главном домене. На главном домене, отдавайте куки с параметром domain .example.com Тогда куки будут видны всем подоменам *.example.com С аяксом тоже есть решения Просто на отдельном домене у вас будут полностью развязаны руки

Re: Cache Revalidate

2013-12-06 Пенетрантность S.A.N
если ревалидация не проходит - элемент кеша не будет удалён/заменён, а будет продолжать использоваться для других пользователей. Если у клиента нет прав доступа, он получает статус 403, если есть права получает – 200 или 304. Если бекенд не отвечает, Nginx отдает 504, никаких

Re: Что значит location / ?

2013-12-18 Пенетрантность S.A.N
# Ключ по которому сохраняются и берутся данные из кеша proxy_cache_key $request_method|$http_if_modified_since|$http_if_none_match|$host|$re quest_uri; Стоит подумать про оптимизацию proxy_cache_key, у вас в ключе есть лишние переменные -

Re: как лучше управлять кешированием fastcgi cache

2013-12-28 Пенетрантность S.A.N
Вам правильно ответили, в первую очередь нужно читать документацию. Возможно вы удивитесь но ваш конфиг по кешированию может и должен выглядить намного короче, как-то так fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s;

Bug – 304 status - Cache-Control

2014-01-01 Пенетрантность S.A.N
Заметили очень неприятный баг, в результате которого, клиенты получали пустую страницу. Конфиг кеширования: 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;

Re: Bug – 304 status - Cache-Control

2014-01-02 Пенетрантность S.A.N
В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по нему ревалидировать. По идеи это временное решения, когда Nginx сделает поддержку ETag можно будет снова его в включить в публичный кеш. Posted at

Re: Bug – 304 status - Cache-Control

2014-01-03 Пенетрантность S.A.N
поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее включать/выключать http://nginx.org/en/docs/http/ngx_http_core_module.html#etag Не забывайте, что еще есть разница между weak/strong E-Tag, согласно RFC

Re: Bug – 304 status - Cache-Control

2014-01-03 Пенетрантность S.A.N
Если вы хотите, чтобы оно работало так, то надо включить в ключ кеширования заголовок If-None-Match - т.к. от него зависит ответ бекенда. Нет, так делать не надо, потому что на один uri может быть только один актуальный ETag, новые значения ETag означают обязательную инвалидацию всех

Re: Bug – 304 status - Cache-Control

2014-01-04 Пенетрантность S.A.N
Есть более красивые решения этой проблемы? А в чем, собственно, состоит проблема? Я вот даже не могу понять - если вы все равно пропускаете все запросы на бекенд для ревалидации по e-tag - зачем у вас включено кеширование на nginx? Не все запросы всегда идут на бекенд, многие из них

Re: Bug – 304 status - Cache-Control

2014-01-04 Пенетрантность S.A.N
А какого рода динамический контент, можете привести пример? Желательно с примером, когда помогает ревалидация. Например, блоги наших клиентов, есть открытые публичные блоги есть закрытые приватные, в каждом блоге возможны комментарии посетителей. Спрогнозировать динамику изменений блога или

Re: Bug – 304 status - Cache-Control

2014-01-04 Пенетрантность S.A.N
Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно - параметры, от которых зависит или может зависеть ответ бекенда, должны быть включены в ключ кеша. Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить проблему, автоматического удаления из запроса к бекенду

Re: Bug – 304 status - Cache-Control

2014-01-04 Пенетрантность S.A.N
О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому, что специально разрешили кешировать 304). А как ведет себя fastcgi_cache_valid 0s Вот кофиг fastcgi_cache cache; fastcgi_cache_lock on;

Re: Bug – 304 status - Cache-Control

2014-01-04 Пенетрантность S.A.N
блоги на каком движке написаны? Блоги - это один из модулей, нашего самописного фреймворка. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246034#msg-246034 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Bug – 304 status - Cache-Control

2014-01-06 Пенетрантность S.A.N
fastcgi_cache_key $host$uri$is_args$args; Это ни разу ни баг - это вы недонастроили. Добавьте в ключ кеширования параметр $http_if_modified_since и наступит вам счастье. Я наверно не доступно объяснию суть проблемы. Попробую объяснить на пальцах :) Есть uri /user/bar Отдает контент

Re: Bug – 304 status - Cache-Control

2014-01-06 Пенетрантность S.A.N
передавать на backend заголовки If-Modified-Since и If-None-Match или нет - это тоже можно настроить по разному для разных location`ов. Да, согласен, но этот вариант очень не хочется реализовывать, довольно большой перечень location придется указывать в конфиге Nginx, это уже жесткий хардкор,

Re: Bug – 304 status - Cache-Control

2014-01-06 Пенетрантность S.A.N
перечитал RFC, к числу hop-by-hop хедеров они не относятся, получается, их надо всегда передавать на бекенд? Да, эти заголовков при прозрачном проксировании передаются без изменений, к сожалению Nginx самостоятельно удаляет эти заговолки при включенном Nginx кешировании, я понимаю почему он

Re: Bug – 304 status - Cache-Control

2014-01-07 Пенетрантность S.A.N
так что Ваш вариант fastcgi_cache_methods GET HEAD; fastcgi_cache_key $host$uri$is_args$args; не оптимален, включает $uri$is_args$args вместо $request_uri и даже ошибочен, потому что не включает в себя $request_method. HEAD кэширует ответ с телом, отдаёт - без. Не хотел обидеть автора

Re: Bug – 304 status - Cache-Control

2014-01-07 Пенетрантность S.A.N
Отдает контент с заголовками Cache-Control: private, max-age=0 если было бы Cache-Control: private, вроде как было бы то же самое, нет ? на 10 символов короче. Можно не указывать max-age=0, по спецификации если не указан max-age он равен нулю, но есть такие клиенты как Opera, у неё

Re: Bug – 304 status - Cache-Control

2014-01-07 Пенетрантность S.A.N
Торг здесь не уместен. Можно написать статью и без ревалидации по ETag. Как реализовать ревалидацию по ETag, если его просто не будет у части клиентов. В кеше ведь всегда находится только один вариант контента - или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем случае

Re: Bug – 304 status - Cache-Control

2014-01-07 Пенетрантность S.A.N
Кстати, похоже, что есть вариант еще проще, используя директиву fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match и выставляя в ответе заголовок X-Accel-Expires: 0 если статус ответа backend`а будет 304. Да, у меня крутился в голове вариант, использовать куки для

Re: proxy cache key и fastcgi cache key

2014-01-09 Пенетрантность S.A.N
Gena Makhomed Wrote: --- возможно имеет смысл дефолтовые настройки сделать такими, чтобы они были безопасными по-умолчанию для всех пользователей? т.е. $host вместо $proxy_host ? Поддержу данную мысль, это добавило бы безопасности дефолтного

Re: Bug – 304 status - Cache-Control

2014-01-09 Пенетрантность S.A.N
0 строчек кода - это невозможно. Все возможно, я выше писал, как я решил эту проблему. В конфиге по прежнему для работы с клиент кешем, установлена передача все нужных заголовком. fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty; fastcgi_param HTTP_IF_MODIFIED_SINCE

Re: proxy cache key и fastcgi cache key

2014-01-10 Пенетрантность S.A.N
Коллизии возможны только в одном случае: программист не проверяет данные, получаемые от клиента, и такому программисту никаким костылями не поможешь. Проверять на бекенде значения Host не рационально, если в конфигурации server указан только один домен. Если следовать вашей логике тогда,

Re: proxy cache key и fastcgi cache key

2014-01-10 Пенетрантность S.A.N
Хочу уточнить, я не предлагаю полную аналогию с UseCanonicalName, я имел виду использовать значения переменной $host, при условии что host из absoluteURI отличается от значения клиентского заголовка Host. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,246275#msg-246275

Re: proxy cache key и fastcgi cache key

2014-01-12 Пенетрантность S.A.N
Для убедительности, приведу ещё такой пример. Есть бекенд приложения, которое обслуживает множество хостов, всех этих хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто невозможно по ряду причин.

Re: High periodic disk I/O

2014-01-14 Пенетрантность S.A.N
Проблема в том, что периодически, раз в 10-20 секунд nginx подгружает диск записью на 2-5 секунды, изза этого случается лаг и например ответ от веб сервера можно ждать несколько секунд. Возможно это результат процесса “cache manager” и/или cache loader Почитать можно здесь

Re: Кэширование статики, которую генерирует бэкэнд

2014-01-20 Пенетрантность S.A.N
Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не препятствовало основному проксированию ответа http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246604,246613#msg-246613

Re: NGinx - Кеширование динамических запросов

2014-02-04 Пенетрантность S.A.N
proxy_cache_key $host$uri; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247093,247095#msg-247095 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-1.5.10

2014-02-04 Пенетрантность S.A.N
Стесняюсь спросить, в какой версии планируется реализацию ревалидации по ETag? :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,247148,247171#msg-247171 ___ nginx-ru mailing list nginx-ru@nginx.org

fastcgi keep conn on и fastcgi finish request() в PHP

2014-02-15 Пенетрантность S.A.N
При включенном keepalive в upstream к FastCGI бекенду на PHP, появляются ошибки 502, проблему нашли и воспроизводится она таким образом. РНР скрипт, медленные операции выполняет в фон режиме после вызова функции fastcgi_finish_request(), тестовый скрипт ?php ignore_user_abort();

Re: fastcgi keep conn on и fastcgi finish request() в PHP

2014-02-20 Пенетрантность S.A.N
Вы прислали FCGI_END_REQUEST, ничего не вернув клиенту, о чём nginx и плачет. Единственное, что он в данном случае может сделать - это вернуть клиенту ошибку. Это происходит только при выключенном fastcgi_keep_conn и keepalive, если их выключить Nginx отлично отдает 200 статус

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-12 Пенетрантность S.A.N
Gena Makhomed Wrote: --- и да, отвечать с 400 статусом тут даже более логично, потому что если authority component в строке запроса и в заголовке Host: разные - это явно попытка взлома. Я так же считаю, что 400 статус в этом случаи должен

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-16 Пенетрантность S.A.N
Maxim Dounin Wrote: --- Какая-либо проблема появляется тогда и только тогда, когда администратор начинает писать в конфиге $http_host, не думая о последствиях. Есть мнение, что совсем простое решение этой проблемы - не делать так (c)

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-16 Пенетрантность S.A.N
Maxim Dounin Wrote: --- Какая-либо проблема появляется тогда и только тогда, когда администратор начинает писать в конфиге $http_host, не думая о последствиях. Есть мнение, что совсем простое решение этой проблемы - не делать

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-17 Пенетрантность S.A.N
Илья Шипицин Wrote: --- а расскажите на примерах, как эту уязвимость можно эксплуатировать? Вариантов эксплойтов очень много: 1. SQL иньекции, когда содержимое HTTP_HOST без экранирования используется в SQL запросах. 2. Хаки в include path,

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-17 Пенетрантность S.A.N
Илья Шипицин Wrote: --- а чем опасен пункт 3) ? мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за ничего. ну ок, в nginx сработал конфиг для одного значения Host, на бекенд улетело другое, что в этом случае может

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-17 Пенетрантность S.A.N
Maxim Dounin Wrote: --- Возможно, когда-нибудь мы и придём к тому, что в таких ситуациях будет возвращаться 400. Но это ни коим образом не избавляет от необходимости исправить приложение. Приведенный мной пример немного утрирован, но взят

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-17 Пенетрантность S.A.N
Илья Шипицин Wrote: --- пока что все озвученные сценарии для пользователя приведут к 400/404/200, ну то есть назло маме отморожу уши. ну ок, пользователь специально сконструировал такой запрос, чтобы он попал в другой хост. ему там ответили

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-17 Пенетрантность S.A.N
Валентин Бартенев Wrote: --- Как уже неоднократно в этой ветке говорилось, nginx в параметрах HTTP_* пишет ровно то, что от него требуется: заголовки, пришедшие от клиента, в том виде, в котором они получены. Nginx так и должен делать, если

Re: Об одной малоизвестной уязвимости в веб сайтах

2014-06-18 Пенетрантность S.A.N
Валентин Бартенев Wrote: --- Вы подменяете понятия. Пока ещё никто из дискутирующих не смог привести аргументов за то, что такие запросы не являются валидными. Я никогда не утверждал, что инвалидность этих запросов определяется стандартом

Cache revalidation using If-None-Match

2014-06-26 Пенетрантность S.A.N
Сегодня, Максим опубликовал патчи которые реализуют указанный функционал, это очень хорошая новость. http://forum.nginx.org/read.php?29,251168 Я так понимаю это финальный код, который войдет в версию Nginx 1.7.3? Так же добавлена возможность использовать не строгие ETag, что тоже очень хорошо...

Re: nginx-1.7.3

2014-07-08 Пенетрантность S.A.N
Добавление: ревалидация элементов кэша теперь, если это возможно, использует заголовок If-None-Match. Отлично, спасибо! Когда появится данная версия в ваших пакетах для CentOS 6? В http://nginx.org/packages/mainline/centos/6/ её ещё нет. Кстати можно уже создавать новую папку

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
proxy_storeon; Может, лучше сделать через кеширования а не дублирования контента? Вот что вам нужно http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251675,251680#msg-251680

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
но картинки так кэшировать не получилось. У вас картинки, хранятся в файлах на том же винте где работает Nginx? Если да, тогда нет смысла их сохранять в локал файлы, по сути будет тоже самое. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251675,251683#msg-251683

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
proxy_cache, полностью сохраняет HTTP ответ от проксированого сервера, в локал файл и следующие запросы отдает из этого локал файла. Но если у вас картинки и так лежат на том же винте в той же файл системе, тогда нет никакого смысла их копировать в другую папку, потому что скорость отдачи будет

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Но если у вас картинки и так лежат на том же винте в той же файл системе, тогда нет никакого смысла их копировать в другую папку, Это я понимаю, просто нет возможности отдавать их напрямую nginx. proxy_cache даст такую же скорость, как и proxy_store ? Просто мне ещё нужно будет выборочно

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Спасибо за советы, а как это будет происходить? Если я например поменял только один файл js. То как nginx узнает, что нужно его обновить в кэше? Получается, что nginx постоянно будет делать запрос к проксированному серверу и спрашивать его заголовки If-Modified-Since” и “If-None-Match”?

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Если я правильно понял, то придёт запрос на статику к nginx он его отправит к Apache, Apache сделает запрос заголовка Last-Modified, добавит к нему max-age=1 и тогда nginx будет повторять эту цепочку каждую секунду. По-моему слишком закручено, для такой задачи. Nginx, будет делать запрос к

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Статика находится в самом приложении и достать в отдельную директорию её нельзя. Поэтому ищу решения с кэшем nginx. Тогда все нормально, вам просто нужно настроить механизм кеширования в Nginx, если ваше приложения общается с Nginx по HTTP тогда Apache конечно ненужен. Posted at Nginx Forum:

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Заголовки запроса не так интересны, вы напишите здесь, HTTP заголовки ответа от вашего приложения. И назначите такой ключ для кеша proxy_cache_key $host$uri$is_args$args Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251675,251701#msg-251701

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Budulianin Wrote: --- Ваш ключ недопустим, поставил такой proxy_cache_key $scheme$proxy_host$uri$is_args$args; Страно, у меня fastcgi_cache_key стоит $host$uri$is_args$args и все норм Ответ: Cache-Control:max-age=5184000

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Спрятать Pragma:no-cache, можно директивой proxy_hide_header http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_hide_header Так с кешем все нормально, все что нужно кешится? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251675,251705#msg-251705

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
В итоге без этой строчки не работает proxy_ignore_headers Cache-Control; Похоже, приложение говорит так nginx не кешить и он не кэшит. А эта строчка игнорирует заголовок и nginx кэшит. Да, так и есть. А как проверить, что именно из кэша отдаётся статика, а не к приложению идёт запрос?

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Поставил, вырубил приложение, на главной странице 502, а статика отдаётся, прикольно. Так может быть, есть смысл и все остальные страницы кешировать, опыт у вас уже есть. Мне ещё нужно рассмотреть вариант хранения кэша в памяти. Если я каталог в который nginx пишет, просто монтирую в память,

Re: proxy story, 304, сброс кэша

2014-07-12 Пенетрантность S.A.N
Просто я пока не знаю других способов, кроме как монтировать в память, но может они есть? Если у вас SSD, или отдача статика происходит за 5-15ms, смысла забирать память под статику я особо не вижу, лучше её отдать приложению и/или БД, но опять же проведите нагрузочное тестирования с макс

Re: Как определить, сколько уже хранится кэш?

2014-07-13 Пенетрантность S.A.N
Если приложения отдает заголовок Last-Modified, он сохраняется в кеше, его значения можно получить в заголовке If-Modified-Since или в конфиге Nginx переменная $upstream_cache_last_modified. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251724,251726#msg-251726

Re: Как определить, сколько уже хранится кэш?

2014-07-13 Пенетрантность S.A.N
Да, это дата модификации контента, она может и не быть равна дате создания кеша, зачем вам именно дата создания кеша? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251724,251729#msg-251729 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Как определить, сколько уже хранится кэш?

2014-07-13 Пенетрантность S.A.N
Cache-Control: max-age=сколько секунд, кеш считается валидным, после истечения этого времени проводится ревалидации Expires: GMT дата, после истечения этой даты проводится ревалидации Pragma - это костыльный заголовок который вообще не стоит использовать для кеширования Материал для обучения

Re: Как определить, сколько уже хранится кэш?

2014-07-13 Пенетрантность S.A.N
Budulianin Wrote: --- Pragma - это костыльный заголовок который вообще не стоит использовать для кеширования Он для HTTP 1.0 Костыльность Pragma, заключается в том что это заголовок запроса а не ответа, потом его начали использовать как

Re: Cache revalidation using If-None-Match

2014-07-14 Пенетрантность S.A.N
Nginx 1.7.3, отличная версия, в ней полностью решен вопрос с ETag. Но есть мелочи которых очень не хватает, их всего две ) 1. Нельзя получить от клиента валидаторы (“If-Modified-Since” и “If-None-Match”) если файла кеша нет, эта ситуация возникает когда бекенд отдавал заголовки Cache-Control:

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Я хочу принять ответ от uwsgi, добавить в него пару заголовков и отдать клиенту. Фактически добавить заголовки в ответ nginx. Я таким образом хочу управлять кэшем. Вы таким образом сможете управлять только кешем браузера, если хотите управлять кешем Nginx, нужно чтобы ваше приложения отдавала

Re: Вопрос об управлении кэшем nginx.

2014-07-15 Пенетрантность S.A.N
Если так uwsgi_ignore_headers X-Accel-Expires Expires Cache-Control Set-Cookie; uwsgi_hide_header Set-Cookie; uwsgi_cache_valid 200 10m; Тогда не важно какие заголовки отправил проксируемый сервер (бекенд), ответ будет закеширован на 10 минут, этим занимается директива

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Да, директивы uwsgi_cache_valid для этого и придумали, чтобы управлять кешированием, если бекенд приложения не может самостоятельно отправить правильные заголовки. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251763,251788#msg-251788 ___

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Budulianin Wrote: --- Зачем вы выбрали такое значения Cache-Control: max-age=600 no-cache? Этой строчкой я хотел сказать браузеру: держи у себя кэш 600 секунд, но при каждом запросе отправляй заголовки(видимо If-modified-since) Потому что

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к серверу вообще, потому что вы ему сказали, что кеш можно использовать без ревалидации на протяжении 600 секунд. После истечения 600 секунд, браузер сделает запрос к серверу, передаст ему If-Modified-Since, Nginx сравнит значения

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Budulianin Wrote: --- В этом случаи приложения должно уметь очень быстро проверять If-Modified-Since с текущим Last-Modified, если они равны отдавать 304, если нет отдавать новый контент и статус 200. Под это нужно специально готовить

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Budulianin Wrote: --- Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к серверу вообще, потому что вы ему сказали, что кеш можно использовать без ревалидации на протяжении 600 секунд. А у меня запросы идут к nginx, те

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Эта схема защитит ваше приложения от нагрузки, но она никак не сможет актуализировать кеш быстрей чем это указанно в max-age. Я же сказал, что мы можем чистить кэш nginx когда нам это нужно. Если у вас есть сторонний процесс который чистит кеш, тогда конечно можно использовать эту схему.

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Значит моя схема вполне жизнеспособна и не выглядит нормально? Кладём основную нагрузку на nginx и немного на браузер. Я думаю да, но лучше проконсультироватся у разработчиков Nginx, как реагирует Nginx если кеш файлы исчезают, без его ведома, я думаю он нормально реагирует, но мало ли какие

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
те кто обновляет страницу в ручную будут получать 304 статус без контента, Только если в запросе, который должен закэшироваться, был заголовок-валидатор(ETag, Last-Modified) иначе нечего будет сравнивать. У меня сейчас нет их и nginx отдаёт 200. С этого и надо было начинать, они нужны

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Budulianin Wrote: --- Это понятно, ревалидировать кеш на в приложении - это стиль RestFull приложений, НЕ в приложении? Я имел виду, ревалидация В приложении это - RESTful стиль. Posted at Nginx Forum:

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Я имел виду, ревалидация В приложении это - RESTful стиль. Не знал, насколько я знаю, обычно REST преподносят, как набор методов(действий), которые можно выполнить с объектом и путь к этому объекту. Да, но не только, основная идея в том, что клиент и сервер могут полностью описать своё

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
С этого и надо было начинать, они нужны обязательно если вы хотите клиенту отдавать 304 без контента. А можно ли создавать ETag и Last-Modified на стороне nginx и для статики и для динамики? есть директива etag on; но написано что она только для статики автоматом вычисляет его. Можно

Re: Нет uwsgi set header, чем заменить?

2014-07-15 Пенетрантность S.A.N
Но все эти детали лучше не говорить тем кто только начинает изучать механизмы кеширования в Nginx ) Почему? Чтобы не пугать, раньше времени ) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251763,251837#msg-251837 ___ nginx-ru mailing

Re: Cache revalidation using If-None-Match

2014-07-15 Пенетрантность S.A.N
Если я правильно понял этот поток текста, то на выходе вы хотите получить что-то вроде The stale-if-error Cache-Control Extension, http://tools.ietf.org/html/rfc5861#section-4. Т.е. возможность задать в заголовках ответа - можно ли этот ответ в дальнейшем использовать при ошибках. Да,

Re: Cache revalidation using If-None-Match

2014-07-15 Пенетрантность S.A.N
Наверно стоит объяснить почему логику кеширования мы вынесли на бекенд и минимально используем конфиг Nginx. Нашим бекендом, пользуются не только браузеры но и мобил приложения, у них логика кеширования очень продвинутая, там учитывается временное пропадания online, в этом случаи клиентское

Re: nginx-1.7.3

2014-07-16 Пенетрантность S.A.N
Пакеты для CentOS 7 доступны. http://nginx.org/en/linux_packages.html#mainline Да, спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251548,251862#msg-251862 ___ nginx-ru mailing list nginx-ru@nginx.org

Re: Cache revalidation using If-None-Match

2014-07-17 Пенетрантность S.A.N
Есть один способ: http://www.lexa.ru/nginx-ru/msg30320.html И второй способ: просто не включать кеширование на стороне nginx в тех location`ах, где оно не нужно. Есть и третий способ if ($upstream_status = 304) { set no_cache = 1; } fastcgi_no_cache $no_cache; Ещё как вариант, Nginx

Re: Cache revalidation using If-None-Match

2014-07-17 Пенетрантность S.A.N
В результате: минимальный overhead, максимальная производительность. В целом я с вами согласен. С удалением валидаторов, можно мирится, ради производительности. Так же можно настроить в конфиге все нужные location в которых нужно выключать кеширования, я тоже знаю как это делать. Просто мне

Re: Cache revalidation using If-None-Match

2014-07-17 Пенетрантность S.A.N
Причина в бекенде, да. Но переписать весь софт правильно - не хватит времени и сил. Например, вот та же MediaWiki. Кстати MediaWiki, использует переменую $_SERVER['HTTP_HOST'] без всякой проверки. Если вы используете MediaWiki, советую поискать в коде $_SERVER['HTTP_HOST'] и изучить степень

Re: Чистка кэша nginx.

2014-07-18 Пенетрантность S.A.N
Я собираюсь иногда чистить его самостоятельно, никаких проблем не должно возникнуть? Скорей всего всё будет без проблем. Проблемы будут если вы начнете редактировать файлы кеша, особенно в новых версиях Nginx. Например если в кеше отредактировать значения ETag, сделать запрос, Nginx уходит в

Re: Cache revalidation using If-None-Match

2014-07-18 Пенетрантность S.A.N
Всеравно nginx отдаст 304 ответ из своего кеша еще быстрее, чем веб-приложение на которое он проксирует запросы клиентов. Да, конечно. Но вы не сможете постоянно хранить ответы в кеше, их придется когда-то ревалидировать. Я долгое время не понимал, необходимости в ревалидации, считал это

Re: Чистка кэша nginx.

2014-07-18 Пенетрантность S.A.N
Всегда их включать? Они так постоянно будут уходить к клиенту. Или только, когда нужно, добавлять в конфиг. Включать всегда их не нужно. Включать нужно только на стадии разработки, для удобства дебага. Так удобней и не придется заглядывать в логи Nginx и в логи приложения, чтобы определить

Re: nginx-1.7.3

2014-09-01 Пенетрантность S.A.N
Пакеты для CentOS 7 доступны. http://nginx.org/en/linux_packages.html#mainline После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с обновлением Nginx. http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html yum update - постоянно пытается обновить

Re: nginx-1.7.3

2014-09-01 Пенетрантность S.A.N
2. с помощью плагина yum-plugin-priorities настроить приоритеты репозиториев таким образом, чтобы у EPEL был более низкий приоритет. это в любом случае полезно настроить для всех используемых репозиториев Спасибо, так и сделали. 3. попросить мантейреров пакета из nginx.org чтобы они

Re: nginx-1.7.3

2014-09-01 Пенетрантность S.A.N
Да, думаю будет правильным если Nginx из ветке mainline, будет иметь Epoch выше чем у ветки stable. Нет. Epoch не надо применять там, где достаточно будет версии пакета. Если значение Epoch одинаково - rpm тогда смотрит на версию пакета. Делать разный Epoch для nginx mainline и nginx

Re: nginx-1.7.3

2014-09-01 Пенетрантность S.A.N
Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше чем у пакета nginx из репозитория EPEL и других сторонних репозиториев. Потому что EPEL содержит много полезных пакетов и его очень часто подключают к CentOS - в том числе и вместе с репозиторием от nginx.org Согласен.

  1   2   3   >