на данный момент меня интересует только необходимость заказа новых ключей,
я правильно понимаю, при включенном forward secrecy приватные ключи утечь не
могли?
Анатолий
On 10 Apr 2014, at 05:26, Илья Шипицин chipits...@gmail.com wrote:
при включенном forward secrecy наличия закрытого ключа (у
Наблюдаю следующую строку в error.log с дефолтным уровнем логирования:
OCSP response not successful (6: unauthorized) while requesting certificate
status, responder: ocsp.comodoca.com
Окружение: Nginx 1.5.13, настройки ssl/tls следующие:
ssl_session_timeout 15m;
ssl_protocols
Доброго времени суток! Пытаюсь настроить редирект для повторяющегося get
параметра. Например ссылка:
http://site.ru/katalog/CD11104/?s-price-min=10s-price-max=50s-configurator-1000=500и
еще несколько s-configurator-x=y?s-cat_id=100
Должна превратиться в ссылку
Hello!
On Thu, Apr 10, 2014 at 07:24:22AM +0100, Anatoly Mikhailov wrote:
на данный момент меня интересует только необходимость заказа новых ключей,
я правильно понимаю, при включенном forward secrecy приватные ключи утечь не
могли?
Нет, вероятность утекания приватных ключей от включённости
Hello!
On Thu, Apr 10, 2014 at 07:42:23AM +0100, Anatoly Mikhailov wrote:
Наблюдаю следующую строку в error.log с дефолтным уровнем логирования:
OCSP response not successful (6: unauthorized) while requesting certificate
status, responder: ocsp.comodoca.com
Окружение: Nginx 1.5.13,
Подскажите, можно ли увеличить лимит PCRE_MATCH_LIMIT, или как лучше тогда
реализовать регулярку?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,249191,249195#msg-249195
___
nginx-ru mailing list
nginx-ru@nginx.org
On Thursday 10 April 2014 08:29:36 a1235530 wrote:
Подскажите, можно ли увеличить лимит PCRE_MATCH_LIMIT, или как лучше тогда
реализовать регулярку?
Увеличит конечно можно, пересобрав pcre с другим значением PCRE_MATCH_LIMIT,
но я не представляю куда уж ещё увеличивать, он по умолчанию 10
Приветствую. Развивая эту недавнюю тему
http://forum.nginx.org/read.php?21,237662 хочу немного доработать логику.
Вместо раздачи каждому пользователю определённого ограничения сделать общее
ограничение и раздать пользователям приоритеты. Итак:
Пусть есть простой запрос:
On Thursday 10 April 2014 16:55:00 cat wrote:
Приветствую. Развивая эту недавнюю тему
http://forum.nginx.org/read.php?21,237662 хочу немного доработать логику.
Вместо раздачи каждому пользователю определённого ограничения сделать общее
ограничение и раздать пользователям приоритеты. Итак:
Хорошо, но запрос на new.ru отрабатывает этот же самый nginx. Как в нем
можно сконвертить get-параметр session обратно в куку, причем удалив его
из числа параметров ?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,249188,249212#msg-249212
так будет работать.
в случае кодов 30X браузер выставляет куку на тот домен, который видит
в Location
да, при желании можно сбрасывать чужие авторизационные куки. читать их нельзя.
насчет add_header для редиректов я действительно не учел, у нас стоит
самодельный патч, который разрешает хедеры на
Здравствуйте, Илья.
Вы писали 10 апреля 2014 г., 23:26:38:
допустим, что сессионная кука называется session, тогда можно сделать так
server {
server_name www.old.ru;
location / {
rewrite ^/(.*)$ http://www.new.ru/$1 permanent;
add_header
спорим, что будет ?
11 апреля 2014 г., 9:59 пользователь Михаил Монашёв
postmas...@softsearch.ru написал:
Здравствуйте, Илья.
Вы писали 10 апреля 2014 г., 23:26:38:
допустим, что сессионная кука называется session, тогда можно сделать так
server {
server_name www.old.ru;
13 matches
Mail list logo
