Maxim Dounin Wrote:
---
>если ревалидация не проходит - элемент кеша не будет
> удалён/заменён, а будет продолжать использоваться для других
> пользователей.
Будет очень полезно, если бекенд сможет через HTTP хедеры управлять,
настройкой cache_
> > если ревалидация не проходит - элемент кеша не будет
> > удалён/заменён, а будет продолжать использоваться для других
> > пользователей.
> Если у клиента нет прав доступа, он получает статус 403, если есть
> права получает – 200 или 304.
> Если бекенд не отвечает, Nginx отдает 504, никаких c
> Just a side note: при ревалидации передаются все заголовки запроса
> пользователя, в том числе куки. Вы куда-то не туда посмотрели.
Да вы правы, куки передаются, это ЕТаг не передается, но в кеше Nginx он
есть.
ЕТаг нужен нам для быстрой проверки прав доступа и версии кеша. Без него на
ранней
Hello!
On Fri, Dec 06, 2013 at 01:56:13AM -0500, grygory.mos wrote:
> > Вот и я о том же - если страница генерится 0.8 секунд, то как
> > может быть недопустимым кешировать её на 1 секунду? Откуда
> > взялось требование о недопустимости?
> >
>
> В моем случаи такое требования появилось, когд
> Вот и я о том же - если страница генерится 0.8 секунд, то как
> может быть недопустимым кешировать её на 1 секунду? Откуда
> взялось требование о недопустимости?
>
В моем случаи такое требования появилось, когда нужно было проверять права
доступа юзера на каждом запросе, но для этого нужны к
Я не имею отношения к Nginx иного, ктоме как пользователь!!!
И пользуюсь firefox'ом.
2013/11/28 S.A.N
> Роман Москвитин Wrote:
> ---
> > Кому как, мне вот только что ответил двухсоткой. Несколько раз.
> > Различный
> > контент пошел уже с 304,
Роман Москвитин Wrote:
---
> Кому как, мне вот только что ответил двухсоткой. Несколько раз.
> Различный
> контент пошел уже с 304, но там и max-age далеко не ноль.
> Про использование кук и прочих ETag я ничего не говорил, но
> кеширование при
>
Кому как, мне вот только что ответил двухсоткой. Несколько раз. Различный
контент пошел уже с 304, но там и max-age далеко не ноль.
Про использование кук и прочих ETag я ничего не говорил, но кеширование при
max-age=0 это совершенно бессмысленное действо с точки зрения банальной
логики.
ибо при пов
> Извините что вклиниваюсь, но это полная победа разума над логикой.
> А идти вразрез с логикой правильно только в алгоритмах защиты, дабы
> спутать
> врага.
Я же не настаиваю на этом решении, это уже вам решать.
Если интересно как юзается max-age=0 для кеширования, далеко ходить не надо,
Google
>
> Если интересно моё мнения, я бы max-age=0 оставил как разрешения на
> кеширования, запретом на кеширования оставить дерективы: no-store,
> no-cache,
> private.
>
Извините что вклиниваюсь, но это полная победа разума над логикой.
А идти вразрез с логикой правильно только в алгоритмах защиты, даб
> - Добавлять комментарий без перезагрузки страницы javascript'ом,
> отправлять на сервер - через ajax. Так, насколько я понимаю,
> сейчас делают чуть менее, чем все, в том числе упоминаемый вами же
> facebook.
Я же написал, что мы знаем как можно работать с задержками, но зачем это всё
Hello!
On Wed, Nov 27, 2013 at 04:21:37PM -0500, S.A.N wrote:
> > use case и о происхождении требования о недопустимости кеширования
> > даже на 1 секунду. Возможно, это позволило бы пересмотреть
> > существующее поведение при max-age=0, благо в Cache-Control есть и
> > другие способы запрета
> А что вам мешает организовать кеш в мемкеше или другом подобном
> хранилище?
> Мы у себя так сделали, кеш (на nginx) выключили вообще за
> ненадобностью.
Мы так же реализуем, слой кеширования в Memcache, в нем кешируются SQL
запросы другие данные, но тесты показывают что ответить 304 намного быс
А что вам мешает организовать кеш в мемкеше или другом подобном хранилище?
Мы у себя так сделали, кеш (на nginx) выключили вообще за ненадобностью.
2013/11/27 S.A.N
> > use case и о происхождении требования о недопустимости кеширования
> > даже на 1 секунду. Возможно, это позволило бы пересмот
Уточнения, там где контент совсем статичный мы кешируем его на долго без
ревалидации.
Постоянная ревалидация нам нужна только на динамичном контенте, все
написанное выше имеет отношения только к динамичному контенту.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,244991,245025#msg-2450
> use case и о происхождении требования о недопустимости кеширования
> даже на 1 секунду. Возможно, это позволило бы пересмотреть
> существующее поведение при max-age=0, благо в Cache-Control есть и
> другие способы запрета кеширования.
use case продиктован нашей бизнес логикой, мы кешируем вс
Hello!
On Wed, Nov 27, 2013 at 02:30:01PM -0500, S.A.N wrote:
> > Они
> > вообще ничего не требуют кешировать. Кеш - дело сугубо
> > добровольное. ;)
>
> max-age=0 не требует кешировать ответ, смысл в том что он не запрещает
> кешировать ответ, в Nginx max-age=0 запрещает кеширования, в этом
> Они
> вообще ничего не требуют кешировать. Кеш - дело сугубо
> добровольное. ;)
max-age=0 не требует кешировать ответ, смысл в том что он не запрещает
кешировать ответ, в Nginx max-age=0 запрещает кеширования, в этом и есть не
соответвия Nginx с спецификацией HTTP.
В Nginx есть деректива fa
Hello!
On Wed, Nov 27, 2013 at 01:22:46PM -0500, S.A.N wrote:
> > А use case какой? С учётом характерных времён доступа по http -
> > запрет кеширования даже на 1 секунду выглядит странно.
>
> Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка
> даже в 1 сек, в отображ
> А use case какой? С учётом характерных времён доступа по http -
> запрет кеширования даже на 1 секунду выглядит странно.
Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка
даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить,
это нормальная практик
27.11.2013 18:06, Maxim Dounin пишет:
Вообще я склонен думать, что тот факт, что X-Accel-Expires в таком
виде работает - это скорее баг. Впрочем, можно его таким и
оставить.
...это скорее баг. Поправим в следующей версии.
___
nginx-ru mailing li
Hello!
On Tue, Nov 26, 2013 at 09:07:51PM -0500, S.A.N wrote:
> Есть досадные мелочи, которые хотелось бы исправить, при включении
> fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда
> отправляется на сервер, даже если кеша нет, бекенду будет отправлен
> параметр с пустым знач
Есть досадные мелочи, которые хотелось бы исправить, при включении
fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда
отправляется на сервер, даже если кеша нет, бекенду будет отправлен
параметр с пустым значением.
По стандартам HTTP при отсутствии кеша, клиент не должен отправл
23 matches
Mail list logo
