Приветствую Есть location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { try_files /cache/$2<???>/$1_$3_$4.jpg /index.php?pid=$1&width=$3&height=$4; } Вместо <???> нужно подставить 00. Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. Временное решение - обьявить переменнуюby sergey.kobzar - Nginx Mailing List - Russian
Игорь On 10/30/12 10:42, Igor Sysoev wrote: > On Oct 30, 2012, at 12:40 , Sergey Kobzar wrote: > >> Максим >> >> On 10/30/12 09:44, Maxim Dounin wrote: >>> Hello! >>> >>> On Tue, Oct 30, 2012 at 03:17:24AM -0400, ak84 wrote: >>> >>>> Максим, добрый день. >>>> Сторонние модуby sergey.kobzar - Nginx Mailing List - Russian
Максим On 10/30/12 09:44, Maxim Dounin wrote: > Hello! > > On Tue, Oct 30, 2012 at 03:17:24AM -0400, ak84 wrote: > >> Максим, добрый день. >> Сторонние модули пробовал отключать в версии 0.8.54 , ситуация повторялась, >> сейчас отключить header_more не могу. > >by sergey.kobzar - Nginx Mailing List - Russian
Максим On 09/20/12 11:12, Maxim Dounin wrote: > Hello! > > On Wed, Sep 19, 2012 at 10:59:50PM +0300, Sergey Kobzar wrote: > > [...] > >> У меня "require verify = sender" давно не используется >> самостоятельно. Слишком много фолс позитивов. > > Речь не идёт о проверby sergey.kobzar - Nginx Mailing List - Russian
On 09/19/12 22:20, Igor Sysoev wrote: >> Я бы не стал рубить при невозможности проверить отправителя. Более >> универсальным решение является сделать скоринговую систему и начислять >> балы каждому письму (не путать с баллами Spaby sergey.kobzar - Nginx Mailing List - Russian
On 09/19/12 14:17, Sergey Budnevitch wrote: > До недавнего времени письма в рассылку с неподписанных адресов переправлялись администратору, > и отправитель оставался в неведении, почему его письмо попало в рассылку с запозданием или нby sergey.kobzar - Nginx Mailing List - Russian
On 09/17/12 00:18, AndrejAndb wrote: > Озадачился вопросом выборочной инвалидацией кэша. > > к примеру следующий use case: > Есть 2 типа страниц: > 1) список статей > 2) статья с пользовательскими комментариями > страницы генерируютсяby sergey.kobzar - Nginx Mailing List - Russian
On 09/13/12 18:39, Vilgelm wrote: > Разобрался, надо было > > fastcgi_param SCRIPT_FILENAME /полный/путь/до/каталога$fastcgi_script_name; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; <- так универсальней будет если объявлен коректный $document_root естественно. __________by sergey.kobzar - Nginx Mailing List - Russian
On 08/26/12 22:34, Alexey V. Karagodov wrote: >>> Подскажите как выкрутится в данной ситуации или придется всетаки сайт вешать на временный домен? >> джумлу можно запускать без апача в теории > даже на практике > так давно запустилby sergey.kobzar - Nginx Mailing List - Russian
On 08/23/12 19:54, Konstantin Gerasimenko wrote: > > > А что будет если nginx отвалится ? или вся ось ? или что то железное и > важное в сервере ? > А может бьть ещо и свич сдохнуть ... топливо на электростанции кончится > ... или даже метиорит пby sergey.kobzar - Nginx Mailing List - Russian
client_max_body_size 64m; При попытке зааплоадить 100М файл получаю Aborted в Firebug и внутреннюю ошибку Firefox. В логах: 2012/08/14 00:43:14 17428#0: *7743 client intended to send too large body: 104857955 bytes, client: 78.94.37.118, server: dev.test.com, request: "POST /qa2/test.php HTTP/1.1", host: "dev.test.com&qby sergey.kobzar - Nginx Mailing List - Russian
Максим On 08/09/12 19:00, Maxim Dounin wrote: >>> Приходит не 200, приходит HTTP/0.9 ответ, потому как у nginx'а >>> кончается буфер и он не знает, какой протокол использовал запрос - и >>> предполагает минимальный из возможных. >> >by sergey.kobzar - Nginx Mailing List - Russian
On 08/09/12 20:29, Maxim Dounin wrote: > Hello! > > On Thu, Aug 09, 2012 at 08:01:43PM +0400, Sergey Shepelev wrote: > >>> Приходит не 200, приходит HTTP/0.9 ответ, потому как у nginx'а >>> кончается буфер и он не знает, какой протокол использовал запрос - и >>> предby sergey.kobzar - Nginx Mailing List - Russian
On 08/09/12 18:46, Maxim Dounin wrote: > Hello! > > On Thu, Aug 09, 2012 at 06:24:41PM +0300, Sergey Kobzar wrote: > > [...] > >>> Error page: >>> error_page 414 /errors/414.html; >>> >>> При длинном URI возвращается кастомная страница с ошибкой, но с кодом >>> ответа 200. Пby sergey.kobzar - Nginx Mailing List - Russian
On 08/09/12 18:20, Sergey Kobzar wrote: > Максим > > Спасибо. См. ниже. > > On 08/08/12 18:50, Maxim Dounin wrote: >> Hello! >> >> On Wed, Aug 08, 2012 at 06:36:20PM +0300, Sergey Kobzar wrote: >> >>> On 08/08/12 18:28, Maxim Dounin wrote: >>>> Hello! >>>> >>>> On Wed, Aug 08, 2012 at 06:11:24PMby sergey.kobzar - Nginx Mailing List - Russian
Максим Спасибо. См. ниже. On 08/08/12 18:50, Maxim Dounin wrote: > Hello! > > On Wed, Aug 08, 2012 at 06:36:20PM +0300, Sergey Kobzar wrote: > >> On 08/08/12 18:28, Maxim Dounin wrote: >>> Hello! >>> >>> On Wed, Aug 08, 2012 at 06:11:24PM +0300, Sergey Kobzar wrote: >>> >>> [...] >>> >>>> Ноby sergey.kobzar - Nginx Mailing List - Russian
On 08/08/12 18:28, Maxim Dounin wrote: > Hello! > > On Wed, Aug 08, 2012 at 06:11:24PM +0300, Sergey Kobzar wrote: > > [...] > >> Но вопрос остается, возможно ли в custom error page на 414 ошибку >> вывести картинку? > > Как минимум три очевидных решения: > > - data:// Не пby sergey.kobzar - Nginx Mailing List - Russian
Максим Спасибо. См. ниже. On 08/08/12 17:51, Maxim Dounin wrote: > On Wed, Aug 08, 2012 at 04:41:20PM +0300, Sergey Kobzar wrote: > >> On 08/08/12 16:39, Sergey Kobzar wrote: >>> On 08/08/12 14:34, Sergey Kobzar wrote: >>>> Есть кастомная страница для 414 ошибки: >>>> >>>> error_page 414 /eby sergey.kobzar - Nginx Mailing List - Russian
On 08/08/12 16:39, Sergey Kobzar wrote: > On 08/08/12 14:34, Sergey Kobzar wrote: >> Есть кастомная страница для 414 ошибки: >> >> error_page 414 /errors/414.html; >> >> Если запрашиваю страницу напрямую http://test.biz/errors/414.html, все >> ОК. >> >> Если вызываю 414 оby sergey.kobzar - Nginx Mailing List - Russian
On 08/08/12 14:34, Sergey Kobzar wrote: > Есть кастомная страница для 414 ошибки: > > error_page 414 /errors/414.html; > > Если запрашиваю страницу напрямую http://test.biz/errors/414.html, все ОК. > > Если вызываю 414 ошибку (Request-URI Too Large), то на некоторых доменах &gby sergey.kobzar - Nginx Mailing List - Russian
Есть кастомная страница для 414 ошибки: error_page 414 /errors/414.html; Если запрашиваю страницу напрямую http://test.biz/errors/414.html, все ОК. Если вызываю 414 ошибку (Request-URI Too Large), то на некоторых доменах все ОК, а на некоторых html отображается нby sergey.kobzar - Nginx Mailing List - Russian
On 07/10/12 12:20, Nick Knutov wrote: > На уровене http есть блок allow ip/mask, после чего deny all; > Это временное решение под ддосом, но при этом хочется, чтобы по факту > deny all отдавался не error 403, а 503, чтобы страницы не выпали из > яндекса. Как эby sergey.kobzar - Nginx Mailing List - Russian
Валентин On 07/09/12 21:45, Валентин Бартенев wrote: >> Я неполно описал задание: >> >> Есть домен domain.com. Необходимо закрыть доступ, где реферером является >> domain<something>.tld или<something>domain.tld (tld может быть отличным >>by sergey.kobzar - Nginx Mailing List - Russian
On 07/09/12 20:43, Валентин Бартенев wrote: > On Monday 09 July 2012 20:50:58 Sergey Kobzar wrote: >> Необходимо сделать отрицание строки в valid_referers. Сейчас >> valid_referers выглядит так: >> >> valid_referers none blocked server_names ~(?!domain); >> >> >> Но если реферby sergey.kobzar - Nginx Mailing List - Russian
Необходимо сделать отрицание строки в valid_referers. Сейчас valid_referers выглядит так: valid_referers none blocked server_names ~(?!domain); Но если реферером выступает домен domain-test.com? то блок if ($invalid_referer) { rewrite ^ /block.php; } Не срабатывает. Что не так?by sergey.kobzar - Nginx Mailing List - Russian
On 05/16/12 17:32, Валентин Бартенев wrote: > On Wednesday 16 May 2012 15:01:52 Ivan wrote: >> под последний стабильный nginx 1.2 не собирается, баг-трекер >> https://dev.vbart.ru/issues/22 не работает ... > > Скажем так, сей "проект" имеет у меня сейчас оченьby sergey.kobzar - Nginx Mailing List - Russian
On 04/27/12 15:51, Denis F. Latypoff wrote: > 27.04.2012, 19:49, "Sergey Kobzar"<sergey.kobzar@itcraft.org>: >> On 04/27/12 15:46, Denis F. Latypoff wrote: >> >>> Да ничем не грозит, просто фронтенд не будет закрывать соединение >>> с бекендом, когда клиент уже отвby sergey.kobzar - Nginx Mailing List - Russian
On 04/27/12 15:46, Denis F. Latypoff wrote: > Да ничем не грозит, просто фронтенд не будет закрывать соединение > с бекендом, когда клиент уже отвалился. > > Вам, вероятно, поможет увеличение proxy_read_timeout на фронтенде. > Или лечить бекенby sergey.kobzar - Nginx Mailing List - Russian
On 04/27/12 14:52, Maxim Dounin wrote: >> Я не совсем понял. Т.е. это фронтенд (proxy) закрывает соединение с >> бэкендом, т.к. время ожидания ответа превысило proxy_read_timeout >> (60s) или все-же пользователь прервал соединение? > > Фронтендby sergey.kobzar - Nginx Mailing List - Russian
Максим On 04/27/12 14:11, Maxim Dounin wrote: > Hello! > > On Fri, Apr 27, 2012 at 01:46:30PM +0300, Sergey Kobzar wrote: > > [...] > >> На фронтэнде: >> 66.249.73.15 - - [27/Apr/2012:11:23:22 +0100] "GET ... HTTP/1.1" 504 >> 9700 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; >> +http://www.google.com/bot.html)&quoby sergey.kobzar - Nginx Mailing List - Russian