Значит, если скрипт, ответ которого кешируется, ставит куки, а nginx их режет, данный способ не подходит. Нужно либо отдельно обрабатывать установку кук, в обход данного механизма кеширования, либо писать куки из скрипта вообще.
Правильно ли я понял первую часть статьи в этом месте:
# Гарантируем, что разные пользователи не получат одну и ту же сессионную Cookie.
fastcgi_hide_header «Set-Cookie»;
Сценарий — заходит Пользователь1, кеш пустой, запрос обрабатывается php, который ставит куку с идентификатором сессии, nginx кладет ответ в кеш и прячет куку.
Заходит Пользователь2. Если я правильно понял, он получит данные из кеша, но при этом не получит куки с идентификатором сессии?
Где вы хеш-таблицу хранить думаете? И как реализацию делать? Если все делать стандартными средствами и хранить данные в самом мемкеше — так я о том и писал, просто реализацию самую простую предложил.
А если дорабатывать сам мемкеш, добавляя ему соответствующий функционал, так проще не изобретать велосипед, а применить другой инструмент, из тех что тут в комментах опоминали или поискать другой.
1. Уверен, что контент который в обычных условиях храниться в мемкеше намного привысит по объему массив самих ключей, даже если у Вас этот массив будет в несколько кБ.
2. Тут так же применимы все техники работы при конкурентном доступе.
Т. е. Вы считаете, что метод топикстартера лучше будет работать с большими объемами ключей и в условиях конкурентного доступа?
А не проще ли хранить все нужные тебе ключи в массиве по отдельному ключу, ну т. е. пользоваться стандартными средствами мемкешеда?
Т. е. записал в мемкешед ключ1-значение1, ключ2-значение2, ..., ключN-значениеN, а по ключу keys-[ключ1, ключ2, ..., ключN] или даже keys-[ключ1-времяЖизни1, ключ2-времяЖизни2, ..., ключ3-времяЖизни3].
В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
Спасибо за интересную статью и тему для обсуждения. Есть еще одна проблема в применение ЭЦП, насколько я знаю - отсутствие судебной практики. Недостаточно прецедентов, ориентируясь на которые можно было бы сказать: "Да, ЭЦП работает".
Например, я работаю в компании, которая хотела бы использоваться ЭПЦ для совершения клиентский операций, чтобы клиент не оригинал бумажного документа нам почтой отправлял, а один раз озаботившись получением сертификата, в течение года все документы предоставлял нам в электронном виде. Наши юристы протестуют против этого, говорят, что если клиент оспорит какой-либо документ, подписанный электронным способом, в суде возникнут проблемы, если не будет бумажного документа с подписью клиента.
Юристы предлагают дублировать все электронные документы, бумажными оригиналами, т. е. ЭЦП используется только для ускорения обслуживания клиента и смысл ее теряется.
Спасибо!
# Гарантируем, что разные пользователи не получат одну и ту же сессионную Cookie.
fastcgi_hide_header «Set-Cookie»;
Сценарий — заходит Пользователь1, кеш пустой, запрос обрабатывается php, который ставит куку с идентификатором сессии, nginx кладет ответ в кеш и прячет куку.
Заходит Пользователь2. Если я правильно понял, он получит данные из кеша, но при этом не получит куки с идентификатором сессии?
А если дорабатывать сам мемкеш, добавляя ему соответствующий функционал, так проще не изобретать велосипед, а применить другой инструмент, из тех что тут в комментах опоминали или поискать другой.
2. Тут так же применимы все техники работы при конкурентном доступе.
Т. е. Вы считаете, что метод топикстартера лучше будет работать с большими объемами ключей и в условиях конкурентного доступа?
Т. е. записал в мемкешед ключ1-значение1, ключ2-значение2, ..., ключN-значениеN, а по ключу keys-[ключ1, ключ2, ..., ключN] или даже keys-[ключ1-времяЖизни1, ключ2-времяЖизни2, ..., ключ3-времяЖизни3].
В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
Например, я работаю в компании, которая хотела бы использоваться ЭПЦ для совершения клиентский операций, чтобы клиент не оригинал бумажного документа нам почтой отправлял, а один раз озаботившись получением сертификата, в течение года все документы предоставлял нам в электронном виде. Наши юристы протестуют против этого, говорят, что если клиент оспорит какой-либо документ, подписанный электронным способом, в суде возникнут проблемы, если не будет бумажного документа с подписью клиента.
Юристы предлагают дублировать все электронные документы, бумажными оригиналами, т. е. ЭЦП используется только для ускорения обслуживания клиента и смысл ее теряется.