From nginx-forum at nginx.us Wed May 1 22:27:11 2013 From: nginx-forum at nginx.us (Karsonito) Date: Wed, 01 May 2013 18:27:11 -0400 Subject: =?UTF-8?B?0J7RiNC40LHQutCwINC+0LPRgNCw0L3QuNGH0LXQvdC40Y8gbGltaXQgem9uZSA=?= =?UTF-8?B?0LIgMC43LjY3LTMrc3F1ZWV6ZTM=?= Message-ID: <0bd3e912192fdcb013f7da43904b2426.NginxMailingListRussian@forum.nginx.org> Возможно это известный факт, но решил сперва посоветоваться. В старой версии 0.7.67-3+squeeze3 действительно присутствует проблема с ограничением по IP? У меня стабильно воспроизводится. Конфиг: http { ... limit_zone perip $binary_remote_addr 10m; limit_conn perip 4; ... } Скрипт для теста sleep.php: Приветствую всех! Стоит следующая задача: Есть web-сервер front - nginx, back - fcgi-php. На него идут upload-ы файлов (несколько десятков клиентов единовременно), необходимо с периодичностью 10-15 секунд, предоставлять информацию стороннему сервису о состояние загрузок (% выполненности или в байтах всего/аплоадед - не принципиально). Как предоставлять - не принципально, т.к. я вообще не могу нагуглить, какой модуль можно для этого использовать (ну или не понял как применить для данной задачи имеющиеся). Бузу очень признателен любой подсказке или направлению гугления. P.S. Всех с первомайскими праздниками! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238783,238783#msg-238783 From vbart at nginx.com Thu May 2 08:35:32 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 2 May 2013 12:35:32 +0400 Subject: =?UTF-8?B?UmU6ICDQntGI0LjQsdC60LAg0L7Qs9GA0LDQvdC40YfQtdC90LjRjyBsaW1pdCB6?= =?UTF-8?B?b25lINCyIDAuNy42Ny0zK3NxdWVlemUz?= In-Reply-To: <0bd3e912192fdcb013f7da43904b2426.NginxMailingListRussian@forum.nginx.org> References: <0bd3e912192fdcb013f7da43904b2426.NginxMailingListRussian@forum.nginx.org> Message-ID: <201305021235.32499.vbart@nginx.com> On Thursday 02 May 2013 02:27:11 Karsonito wrote: > Возможно это известный факт, но решил сперва посоветоваться. > В старой версии 0.7.67-3+squeeze3 действительно присутствует проблема с > ограничением по IP? Старая версия - это 1.2.1, а 0.7.67 - это уже музейный экспонат. > > У меня стабильно воспроизводится. > Конфиг: > http { > ... > limit_zone perip $binary_remote_addr 10m; У вас тут имя зоны "perip". > limit_conn perip 4; > ... > } > > Скрипт для теста sleep.php: > sleep(1); > > Запускаю: > ab -v 2 -c 4 -n 1000 http://127.0.0.1/sleep.php > Все запросы принимаются, ограничение не срабатывает. > Одновременно с первым ab запускаю второй: > ab -v 2 http://192.168.0.1/sleep.php > И сразу получаю 503 > В журнале: limiting connections by zone "conns", client: 192.168.0.1, > server: , request: "GET /sleep.php HTTP/1.0", host: "192.168.0.1" А тут "conns". Либо вы запускаете не с тем конфигом, что приведен выше, либо он содержит ещё какие-то ограничения, помимо представленных. И не стоит надеяться на честность ab. Рекомендую повторить тест более простыми средствами. -- Валентин Бартенев http://nginx.org/en/donation.html > > Проще говоря, nginx ограничивает если одновременно обрабатывается больше > чем указано в limit_conn, не обращая внимания на limit_zone. > > Попробовал тот же конфиг на 1.2.1-2.2~bpo60+2 - все работает корректно. > Ограничение сработало только для соединений с одного IP. > > Я не ошибся? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238781,238781#msg-238781 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From uncleandyv at gmail.com Thu May 2 10:30:05 2013 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Thu, 2 May 2013 14:30:05 +0400 Subject: =?UTF-8?B?UmU6INCY0YnRgyDRgNC10YjQtdC90LjRjyDQtNC70Y8g0L3QtdGB0YLQsNC90LQ=?= =?UTF-8?B?0LDRgNGC0L3QvtCz0L4gdXBsb2FkIHByb2dyZXNzLdCw?= In-Reply-To: <6e06075f071f125cc079d88a7af6d9f3.NginxMailingListRussian@forum.nginx.org> References: <6e06075f071f125cc079d88a7af6d9f3.NginxMailingListRussian@forum.nginx.org> Message-ID: Что-то я не совсем понял. А чем не подходит стандартный nginx модуль nginx_upload_module? Насколько я понимаю, он может предоставлять информацию о прогрессе закачки любому клиенту, который знает идентификатор файла. Я его использовал в своих проектах для обычного варианта показа загрузки клиенту, но с тем-же успехом его можно использовать и для показа прогресса третьей стороне. Главное что-бы третья сторона знала идентификаторы закачиваемых файлов. 2 мая 2013 г., 9:21 пользователь pioneer32 написал: > Приветствую всех! > > Стоит следующая задача: > Есть web-сервер front - nginx, back - fcgi-php. На него идут upload-ы > файлов > (несколько десятков клиентов единовременно), необходимо с периодичностью > 10-15 секунд, предоставлять информацию стороннему сервису о состояние > загрузок (% выполненности или в байтах всего/аплоадед - не принципиально). > Как предоставлять - не принципально, т.к. я вообще не могу нагуглить, какой > модуль можно для этого использовать (ну или не понял как применить для > данной задачи имеющиеся). > > Бузу очень признателен любой подсказке или направлению гугления. > > P.S. Всех с первомайскими праздниками! > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,238783,238783#msg-238783 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Thu May 2 11:41:48 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 2 May 2013 12:41:48 +0100 Subject: =?UTF-8?B?UmU6INCY0YnRgyDRgNC10YjQtdC90LjRjyDQtNC70Y8g0L3QtdGB0YLQsNC90LQ=?= =?UTF-8?B?0LDRgNGC0L3QvtCz0L4gdXBsb2FkIHByb2dyZXNzLdCw?= In-Reply-To: References: <6e06075f071f125cc079d88a7af6d9f3.NginxMailingListRussian@forum.nginx.org> Message-ID: On May 2, 2013, at 11:30 AM, Andrey Velikoredchanin wrote: > Что-то я не совсем понял. А чем не подходит стандартный nginx модуль nginx_upload_module? Насколько я понимаю, он может предоставлять информацию о прогрессе закачки любому клиенту, который знает идентификатор файла. Я его использовал в своих проектах для обычного варианта показа загрузки клиенту, но с тем-же успехом его можно использовать и для показа прогресса третьей стороне. Главное что-бы третья сторона знала идентификаторы закачиваемых файлов. > В каком смысле "стандартный" модуль? Это тот, который несовместим с Nginx 1.3.9+ и был заброшен автором на произвол судьбы? читать тут https://github.com/vkholodkov/nginx-upload-module/issues/41#issuecomment-15692917 Существуют попытки патчить этот модуль для новых версий Nginx, но вопрос - зачем, если Nginx сам и так умеет делать 80% того, что нужно? Есть стандартная функциональность client_body_in_file_only, есть официальная документация, можно также почитать тут https://coderwall.com/p/swgfvw В процессе аплоада файла можно узнать размер файла в temp dir и вычислить проценты от общего объема, однако как вычислить имя тестового файла это вопрос к Максиму и Валентину, можно ли так сделать? Анатолий > > 2 мая 2013 г., 9:21 пользователь pioneer32 написал: > Приветствую всех! > > Стоит следующая задача: > Есть web-сервер front - nginx, back - fcgi-php. На него идут upload-ы файлов > (несколько десятков клиентов единовременно), необходимо с периодичностью > 10-15 секунд, предоставлять информацию стороннему сервису о состояние > загрузок (% выполненности или в байтах всего/аплоадед - не принципиально). > Как предоставлять - не принципально, т.к. я вообще не могу нагуглить, какой > модуль можно для этого использовать (ну или не понял как применить для > данной задачи имеющиеся). > > Бузу очень признателен любой подсказке или направлению гугления. > > P.S. Всех с первомайскими праздниками! > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238783,238783#msg-238783 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu May 2 11:51:24 2013 From: nginx-forum at nginx.us (Karsonito) Date: Thu, 02 May 2013 07:51:24 -0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQvtCz0YDQsNC90LjRh9C10L3QuNGPIGxpbWl0IHpv?= =?UTF-8?B?bmUg0LIgMC43LjY3LTMrc3F1ZWV6ZTM=?= In-Reply-To: <201305021235.32499.vbart@nginx.com> References: <201305021235.32499.vbart@nginx.com> Message-ID: <3f047a1804fedc5f0f3cbaa73b575266.NginxMailingListRussian@forum.nginx.org> > Старая версия - это 1.2.1, а 0.7.67 - это уже музейный экспонат. Увы, но в стабильном debian squeeze это официальная версия. Я конечно поздновато спохватился (через пару дней выйдет debian wheezy), но все-таки хотелось прояснить почему у меня были проблемы. > У вас тут имя зоны "perip". ... > А тут "conns". Либо вы запускаете не с тем конфигом, что приведен выше, либо он содержит ещё какие-то ограничения, помимо представленных. Прошу прощения - сообщение из журнала от старого конфига. Но сути не меняет. >И не стоит надеяться на честность ab. Рекомендую повторить тест более простыми средствами. Более простыми тоже пробовал - стабильная 503. Я бы и не заметил этого если бы не попробовал в продакшине. Были постоянные 503 когда подключалось много клиентов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238785,238789#msg-238789 From nginx-forum at nginx.us Thu May 2 13:02:16 2013 From: nginx-forum at nginx.us (pioneer32) Date: Thu, 02 May 2013 09:02:16 -0400 Subject: =?UTF-8?B?UmU6INCY0YnRgyDRgNC10YjQtdC90LjRjyDQtNC70Y8g0L3QtdGB0YLQsNC90LQ=?= =?UTF-8?B?0LDRgNGC0L3QvtCz0L4gdXBsb2FkIHByb2dyZXNzLdCw?= In-Reply-To: References: Message-ID: Я походу не совсем корректно выразился, опишу на примере, как бы меня вполне устроило: Есть N клиентов, которые ассинхронно аплоадят файлы на веб-сервер. Есть сервер 2, который регулярно обращается к веб-серверу и получает моментальное состояние аплоадов всех клиентов: клиент 1 - 10%, клиент 2 - 5% и т.п (либо наоборот некий процесс на веб-сервере "сливает" информацию на сервер 2). Клиенты, прежде чем начать заливать файлы - уведомляют об этом сервер 2, т.е. он "в курсе" какой клиент (ip и т.п.), какой файл (имя размер) будет заливать. nginx_upload_module - как я понял, он совсем для других задач, хотя я не изучал вопроса, как его можно использовать для моей задачи. я смотрел в сторону nginx_uploadprogress_module - а он, как я понял, репортует о прогрессе клиенту который файл аплоадид, а мне нужно серверу 2 client_body_in_file_only - для данного случая совсем не применима, т.к. пока ждинкс request body не получил, он не устанавливает переменную $request_body_file, соответственно я не знаю в какой темп файл боди кладется. И кстати там будет raw боди, из него еще надо "вытащить" контент файла. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238783,238791#msg-238791 From vbart at nginx.com Thu May 2 13:33:44 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 2 May 2013 17:33:44 +0400 Subject: =?UTF-8?B?UmU6ICDQntGI0LjQsdC60LAg0L7Qs9GA0LDQvdC40YfQtdC90LjRjyBsaW1pdCB6?= =?UTF-8?B?b25lINCyIDAuNy42Ny0zK3NxdWVlemUz?= In-Reply-To: <3f047a1804fedc5f0f3cbaa73b575266.NginxMailingListRussian@forum.nginx.org> References: <201305021235.32499.vbart@nginx.com> <3f047a1804fedc5f0f3cbaa73b575266.NginxMailingListRussian@forum.nginx.org> Message-ID: <201305021733.44501.vbart@nginx.com> On Thursday 02 May 2013 15:51:24 Karsonito wrote: > > Старая версия - это 1.2.1, а 0.7.67 - это уже музейный экспонат. > > Увы, но в стабильном debian squeeze это официальная версия. > > Я конечно поздновато спохватился (через пару дней выйдет debian wheezy), но > все-таки хотелось прояснить почему у меня были проблемы. Официальная версия находится тут: http://nginx.org/en/linux_packages.html Всё остальное может не только содержать известные баги и уязвимости, но и сторонние модули и патчи, в т.ч. очень сомнительного качества. > > > У вас тут имя зоны "perip". > > ... > > > А тут "conns". Либо вы запускаете не с тем конфигом, что приведен выше, > > либо он содержит ещё какие-то ограничения, помимо представленных. > Прошу прощения - сообщение из журнала от старого конфига. Но сути не > меняет. > > >И не стоит надеяться на честность ab. Рекомендую повторить тест более > > простыми средствами. > Более простыми тоже пробовал - стабильная 503. > Я бы и не заметил этого если бы не попробовал в продакшине. Были постоянные > 503 когда подключалось много клиентов. > Мне не известно о каких-либо серьезных правках в модуле limit_conn или переменной $binary_remote_addr на эту тему, а равно как и changelog не содержит соответствующей информации. Я ради интереса даже специально собрал nginx 0.7.67 и попробовал с вашим конфигом - всё прекрасно работает. Так что полагаю проблема, либо в том, как вы тестируете, либо в конкретной сборке, которую распространяют майнтейнеры вашего дистрибутива. -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Thu May 2 13:36:40 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 2 May 2013 17:36:40 +0400 Subject: =?UTF-8?B?UmU6ICDQmNGJ0YMg0YDQtdGI0LXQvdC40Y8g0LTQu9GPINC90LXRgdGC0LDQvdC0?= =?UTF-8?B?0LDRgNGC0L3QvtCz0L4gdXBsb2FkIHByb2dyZXNzLdCw?= In-Reply-To: References: Message-ID: <201305021736.40837.vbart@nginx.com> On Thursday 02 May 2013 17:02:16 pioneer32 wrote: > Я походу не совсем корректно выразился, опишу на примере, как бы меня > вполне устроило: > > Есть N клиентов, которые ассинхронно аплоадят файлы на веб-сервер. Есть > сервер 2, который регулярно обращается к веб-серверу и получает > моментальное состояние аплоадов всех клиентов: клиент 1 - 10%, клиент 2 - > 5% и т.п (либо наоборот некий процесс на веб-сервере "сливает" информацию > на сервер 2). > > Клиенты, прежде чем начать заливать файлы - уведомляют об этом сервер 2, > т.е. он "в курсе" какой клиент (ip и т.п.), какой файл (имя размер) будет > заливать. [...] Почему бы тогда клиентам не уведомлять сервер 2 и о ходе закачки? -- Валентин Бартенев http://nginx.org/en/donation.html From ufaweb at gmail.com Thu May 2 14:41:40 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Thu, 2 May 2013 20:41:40 +0600 Subject: =?UTF-8?B?UmU6INCY0YnRgyDRgNC10YjQtdC90LjRjyDQtNC70Y8g0L3QtdGB0YLQsNC90LQ=?= =?UTF-8?B?0LDRgNGC0L3QvtCz0L4gdXBsb2FkIHByb2dyZXNzLdCw?= In-Reply-To: <201305021736.40837.vbart@nginx.com> References: <201305021736.40837.vbart@nginx.com> Message-ID: http://wiki.nginx.org/HttpUploadProgressModule (есть в составе пакета nginx-extras для debian wheezy и ubuntu) решит вашу задачу, вариант же с client_body_in_file_only кажется интересным, но мне не понятно как определить имя временного файла и самое главное как его (имя) передать какому-либо обработчику, чтобы тот смог отслеживать изменение размера этого файла. 2 мая 2013 г., 19:36 пользователь Валентин Бартенев написал: > On Thursday 02 May 2013 17:02:16 pioneer32 wrote: >> Я походу не совсем корректно выразился, опишу на примере, как бы меня >> вполне устроило: >> >> Есть N клиентов, которые ассинхронно аплоадят файлы на веб-сервер. Есть >> сервер 2, который регулярно обращается к веб-серверу и получает >> моментальное состояние аплоадов всех клиентов: клиент 1 - 10%, клиент 2 - >> 5% и т.п (либо наоборот некий процесс на веб-сервере "сливает" информацию >> на сервер 2). >> >> Клиенты, прежде чем начать заливать файлы - уведомляют об этом сервер 2, >> т.е. он "в курсе" какой клиент (ip и т.п.), какой файл (имя размер) будет >> заливать. > [...] > > Почему бы тогда клиентам не уведомлять сервер 2 и о ходе закачки? > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Шарипов Руслан. Руководитель отдела разработки и сопровождения программного обеспечения ОАО "Уфанет". Контактная информация: google+: http://gplus.to/ruslan jid: serafim at jabber.ufanet.ru wave: ufaweb at googlewave.com skype: ufaweb phone: +7(917)4775460 vkontakte: http://vkontakte.ru/ufaweb myspace: http://www.myspace.com/ufaweb facebook: http://facebook.com/sharipov linkedin: http://www.linkedin.com/in/ufaweb twitter: http://twitter.com/ufaweb From nginx-forum at nginx.us Sat May 4 21:04:12 2013 From: nginx-forum at nginx.us (CYB3R) Date: Sat, 04 May 2013 17:04:12 -0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDQvdCw0L/QuNGB0LDRgtGMINC60L7QvdGE0LjQsw==?= Message-ID: <310868273c7e3273b51ae5ad6d35a476.NginxMailingListRussian@forum.nginx.org> Привет всем! На ЛОРе посоветовали обратиться на форум nginx (http://www.linux.org.ru/forum/admin/9128165?cid=9128167), не уверен, что пишу туда, куда следует. Недавно снёс tomcat, поставил nginx и обрадовался, как же мало памяти он кушает. Но с конфигами всё не так просто, как я ожидал. Для начала хотел сделать три простые вещи: 1. Перенаправлять с http://mysite.lol/dir/whatever.html на http://mysite.lol/dir/whatever; 2. Соответственно по адресу http://mysite.lol/dir/whatever отображать содержимое http://mysite.lol/dir/whatever.html; 3. Перенаправлять с http://mysite.lol/dir/index.html (и, наверно, http://mysite.lol/dir/whatever, тут от порядка правил зависит) на http://mysite.lol/dir/, чтобы избежать дублирования контента. Написал такие правила: > rewrite ^(.*)\.html$ $1 permanent; > rewrite ^(.*)/index$ $1 permanent; > try_files $uri.html $uri/ =404; Подскажите, пожалуйста, как написать это правильно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238844,238844#msg-238844 From psixozzz at gmail.com Sun May 5 14:22:57 2013 From: psixozzz at gmail.com (psixozzz at gmail.com) Date: Sun, 5 May 2013 20:22:57 +0600 Subject: =?UTF-8?B?0JrRgNC+0YHRgdC00L7QvNC10L3QvdCw0Y8g0LDQstGC0L7RgNC40LfQsNGG0Lg=?= =?UTF-8?B?0Y8g0YHRgNC10LTRgdGC0LDQstC80Lggbmdpbng=?= Message-ID: <15710675846.20130505202257@gmail.com> Здравствуйте, Nginx-ru. Дано: домен с большим количеством поддоменов. Задача: открыть доступ только для ограниченного круга лиц, включая мобильные клиенты. Крайне желательно ограничиться средствами nginx, не вмешиваясь в скрипты сайта. Авторизация нужна только для того, чтобы не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое, как, например, факт наличия куки у клиента и т.п. Никак не могу придумать, как это реализовать. Basic-авторизация не подходит, т.к. она не кроссдоменная. Рассматривал вариант когда сайт не пускает никого, у кого нет определенной куки, а получить ее можно, зайдя на определенный урл внутри сайта. Возникли проблемы с внесением изменений в текущую конфигурацию nginx: if ($cookie_edws != '1033'){ return 444; } location = /auth_url { add_header Set-Cookie "lcid=1033;Domain=.domain.com;Path=/;Max-Age=31536000"; rewrite ^(.*)$ domain.com persistent; } if (!-e $request_filename) { rewrite ^(.*)$ /index.php break; } Таким образом, если физически auth_url не существует, то управление в location = /auth_url не попадет никогда, а всегда будет передано в if (-e $request_filename). Даже если вмешаться в структуру сайта (что неприемлимо) и создать файл auth_url, то в location управление не попадет из-за существования if ($cookie_edws != '1033'). Замкнутый круг какой-то. Может многоуважаемый All подскажет как быть? -- С уважением, Psixozzz mailto:psixozzz at gmail.com From panfilov at sports.ru Mon May 6 13:53:20 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Mon, 6 May 2013 17:53:20 +0400 Subject: =?UTF-8?B?0LfQsNC/0YPRgtCw0L3QvdC+0YHRgtGMINC90LDRgdGC0YDQvtC50LrQuCBwcm94?= =?UTF-8?B?eV9zZXRfaGVhZGVy?= Message-ID: Наткнулся на не очень очевидную вещь с директивой proxy_set_header: Если на уровне указана эта директива, то все настройки этой директивы с предыдущих уровней пропадают. При этом на уровнях без этой директивы всё прекрасно наследуется. Не смотря на указание такого поведения в документации, считаю это не очевидным и запутывающим настройку. Предлагаю, включить наследование это директивы вне зависимости от от наличия директивы на уровне с новой current-версии :) . На уровне разрешить лишь переопределение директивы. -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon May 6 14:14:42 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 6 May 2013 18:14:42 +0400 Subject: =?UTF-8?B?UmU6ICDQt9Cw0L/Rg9GC0LDQvdC90L7RgdGC0Ywg0L3QsNGB0YLRgNC+0LnQutC4?= =?UTF-8?B?IHByb3h5X3NldF9oZWFkZXI=?= In-Reply-To: References: Message-ID: <201305061814.42857.vbart@nginx.com> On Monday 06 May 2013 17:53:20 Михаил Панфилов wrote: > Наткнулся на не очень очевидную вещь с директивой proxy_set_header: > > Если на уровне указана эта директива, то все настройки этой директивы с > предыдущих уровней пропадают. При этом на уровнях без этой директивы всё > прекрасно наследуется. Не смотря на указание такого поведения в > документации, считаю это не очевидным и запутывающим настройку. Так наследуются практически все директивы в nginx, кроме нескольких исключений, которые не наследуются вообще. -- Валентин Бартенев http://nginx.org/en/donation.html > > Предлагаю, включить наследование это директивы вне зависимости от от > наличия директивы на уровне с новой current-версии :) . На уровне разрешить > лишь переопределение директивы. From mdounin at mdounin.ru Mon May 6 14:24:29 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 6 May 2013 18:24:29 +0400 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YLQsNC90L3QvtGB0YLRjCDQvdCw0YHRgtGA0L7QudC60Lgg?= =?UTF-8?B?cHJveHlfc2V0X2hlYWRlcg==?= In-Reply-To: References: Message-ID: <20130506142429.GO69760@mdounin.ru> Hello! On Mon, May 06, 2013 at 05:53:20PM +0400, Михаил Панфилов wrote: > Наткнулся на не очень очевидную вещь с директивой proxy_set_header: > > Если на уровне указана эта директива, то все настройки этой директивы с > предыдущих уровней пропадают. При этом на уровнях без этой директивы всё > прекрасно наследуется. Не смотря на указание такого поведения в > документации, считаю это не очевидным и запутывающим настройку. > > Предлагаю, включить наследование это директивы вне зависимости от от > наличия директивы на уровне с новой current-версии :) . На уровне разрешить > лишь переопределение директивы. И как вы будете решать задачу вида location /foo { # тут передать заголовки: # X-Foo: 1 # X-Foo: 2 location /foo/bar { # тут передать заголовки: # X-Foo: 3 # X-Foo: 4 } } ? Вообще - так работают все директивы в nginx'е, и не стоит расчитывать, что это изменится. Я бы рекомендовал для начала попытаться понять, как и почему оно работает именно так. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue May 7 11:29:30 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 May 2013 15:29:30 +0400 Subject: nginx-1.5.0 Message-ID: <20130507112929.GB69760@mdounin.ru> Изменения в nginx 1.5.0 07.05.2013 *) Безопасность: при обработке специально созданного запроса мог перезаписываться стек рабочего процесса, что могло приводить к выполнению произвольного кода (CVE-2013-2028); ошибка появилась в 1.3.9. Спасибо Greg MacManus, iSIGHT Partners Labs. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue May 7 11:29:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 May 2013 15:29:59 +0400 Subject: nginx-1.4.1 Message-ID: <20130507112959.GF69760@mdounin.ru> Изменения в nginx 1.4.1 07.05.2013 *) Безопасность: при обработке специально созданного запроса мог перезаписываться стек рабочего процесса, что могло приводить к выполнению произвольного кода (CVE-2013-2028); ошибка появилась в 1.3.9. Спасибо Greg MacManus, iSIGHT Partners Labs. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue May 7 11:30:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 7 May 2013 15:30:31 +0400 Subject: nginx security advisory (CVE-2013-2028) Message-ID: <20130507113031.GJ69760@mdounin.ru> Hello! Greg MacManus из iSIGHT Partners Labs обнаружил проблему безопасности в нескольких последних версиях nginx. При обработке специально созданного запроса мог перезаписываться стек рабочего процесса, что могло приводить к выполнению произвольного кода (CVE-2013-2028). Проблеме подвержены версии nginx 1.3.9 - 1.4.0. Проблема исправлена в nginx 1.5.0, 1.4.1. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2013.chunked.txt В качестве временной защиты можно в каждом блоке server{} воспользоваться конфигурацией вида: if ($http_transfer_encoding ~* chunked) { return 444; } -- Maxim Dounin http://nginx.org/en/donation.html From bogdar at gmail.com Tue May 7 16:25:13 2013 From: bogdar at gmail.com (Bogdan) Date: Tue, 7 May 2013 19:25:13 +0300 Subject: =?UTF-8?B?ZW1wdHlfZ2lmINC4INC90YPQu9C10LLQvtC5ICRyZXF1ZXN0X3RpbWU=?= Message-ID: Добрый день. Для запросов обрабатываемых локейшеном empty_gif из ngx_http_empty_gif_module в лог пишется нулевое время выполнения запроса, точнее "0.000" Я проверил снифером - у меня выходит, например, между tcp-пакетом содержащим http GET и пакетом с пикселем порядка 0.02 sec, общая продолжительность tcp-сессии - 0.048 sec, а в логах всё время нули. Подскажите пожалуйста, есть ли возможность логировать время выполнения запросов для такого локейшена? Nginx 1.4.0, Debian 6 amd64 Спасибо! -- WBR, Bogdan B. Rudas -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Tue May 7 17:10:56 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 7 May 2013 21:10:56 +0400 Subject: =?UTF-8?B?UmU6IGVtcHR5X2dpZiDQuCDQvdGD0LvQtdCy0L7QuSAkcmVxdWVzdF90aW1l?= In-Reply-To: References: Message-ID: <1172012159.20130507211056@softsearch.ru> Здравствуйте, Bogdan. > Для запросов обрабатываемых локейшеном empty_gif из > ngx_http_empty_gif_module в лог пишется нулевое время выполнения > запроса, точнее "0.000" > Я проверил снифером - у меня выходит, например, между tcp-пакетом > содержащим http GET и пакетом с пикселем порядка 0.02 sec, общая > продолжительность tcp-сессии - 0.048 sec, а в логах всё время нули. > Подскажите пожалуйста, есть ли возможность логировать время > выполнения запросов для такого локейшена? Если я правильно понимаю, то nginx отдая всё в ядро, а уже само ядро отдавало пакеты долго. -- С уважением, Михаил mailto:postmaster at softsearch.ru From valery+nginxru at grid.net.ru Tue May 7 19:37:38 2013 From: valery+nginxru at grid.net.ru (Valery Kholodkov) Date: Tue, 07 May 2013 21:37:38 +0200 Subject: resumable upload In-Reply-To: <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> Message-ID: <51895802.2080008@grid.net.ru> On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: > > On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: > >> On 29.03.2013 17:02, Валентин Бартенев wrote: >>> Просто когда дело заходит о том, что на грамотную реализацию и последующую >>> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >>> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >>> оно и нужно было. >> Большинство вопрошающих вполне устраивал upload_module. >> >> P.S. Пожалуй, это тупиковая ветвь дискуссии. > > тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку > уже как полгода. Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё будет". Однако, я считатю, что подобный ответ не соответствует моему уровню. Предлагаемая бизнес-модель не работает, я проверил это на собственном опыте. В то же время, поддерживать этот модуль на собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос из nginx (sic!). Nginx меня многому научил, и у меня появилось множество идей того, как всевозможные вещи реализовать на более высоком уровне, гибче и доступнее. Более того, часть из своих гипотез я уже успел проверить. Однако, я пока не уверен, что это выльется в конкретный проект. Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, несмотря на то, что в nginx достаточно было бы поправить несколько строк. -- Best regards, Valery Kholodkov From anatoly at sonru.com Tue May 7 22:19:43 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 7 May 2013 23:19:43 +0100 Subject: resumable upload In-Reply-To: <51895802.2080008@grid.net.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> Message-ID: <1E892F4A-9CE0-4192-9C06-C786989F73A3@sonru.com> On May 7, 2013, at 8:37 PM, Valery Kholodkov wrote: > On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: >> >> On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: >> >>> On 29.03.2013 17:02, Валентин Бартенев wrote: >>>> Просто когда дело заходит о том, что на грамотную реализацию и последующую >>>> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >>>> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >>>> оно и нужно было. >>> Большинство вопрошающих вполне устраивал upload_module. >>> >>> P.S. Пожалуй, это тупиковая ветвь дискуссии. >> >> тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку >> уже как полгода. > > Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. > > Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё будет". > > Однако, я считатю, что подобный ответ не соответствует моему уровню. Предлагаемая бизнес-модель не работает, я проверил это на собственном опыте. В то же время, поддерживать этот модуль на собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос из nginx (sic!). > > Nginx меня многому научил, и у меня появилось множество идей того, как всевозможные вещи реализовать на более высоком уровне, гибче и доступнее. Более того, часть из своих гипотез я уже успел проверить. Однако, я пока не уверен, что это выльется в конкретный проект. > > Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, несмотря на то, что в nginx достаточно было бы поправить несколько строк. > Классно, проекты с миллионами посетителей каждый день обслуживает nginx с весьма минимальными ресурсо-затратами, CEO Github говорит лично Игорю Сысоеву спасибо, Wordress спонсирует SPDY модуль, Netflix зарабатывает миллиарды, используя Nginx как платформу для https-стриминга, а мы рассуждаем о бизнес-модели, работает она или нет. Валерий, Ваш замечательный плагин по-прежнему используется и многие разочарованы отсутствием его поддержки, это и стало основной причиной этого треда (28 марта 2013). Честно, очень жаль, что Вы выросли из Nginx. Анатолий > -- > Best regards, > Valery Kholodkov > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Tue May 7 22:32:07 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 7 May 2013 23:32:07 +0100 Subject: =?UTF-8?Q?Gzip_=D0=B8_ETag?= Message-ID: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? Анатолий From anatoly at sonru.com Tue May 7 22:43:02 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 7 May 2013 23:43:02 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> Message-ID: <7D70A860-F6FA-44D2-8B7F-6B9A7B3F8E42@sonru.com> On May 7, 2013, at 11:32 PM, Anatoly Mikhailov wrote: > Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, > ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). > Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. > > Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, > и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. > Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? о чем-то подобном писали здесь несколько дней назад: https://github.com/pagespeed/ngx_pagespeed/issues/70 > > Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue May 7 23:23:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 03:23:04 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> Message-ID: <20130507232304.GR69760@mdounin.ru> Hello! On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: > Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, > ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). > Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. > > Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, > и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. > Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? При любых изменениях тела ответа, в том числе - модулем gzip, ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, чтобы strong etags у ответов совпадали тогда и только тогда, когда ответы совпадают до байта. (А если ответы будет не совпадать при одинаковых ETag'ах - это в свою очередь чревато получением неверного суммарного ответа при комбинировании нескольких ответов на range-запросы.) Почитать подробности можно тут (и далее по ссылкам): http://tools.ietf.org/html/rfc2616#section-3.11 В качестве оптимизации - можно обучить nginx отделять weak etags от strong etags, и убирать только strong. Но для начала имеет смысл понять - надо ли оно на самом деле. -- Maxim Dounin http://nginx.org/en/donation.html From isk at cupid.com Wed May 8 06:23:41 2013 From: isk at cupid.com (Olexander Shtepa) Date: Wed, 8 May 2013 09:23:41 +0300 Subject: =?UTF-8?B?UmU6IGVtcHR5X2dpZiDQuCDQvdGD0LvQtdCy0L7QuSAkcmVxdWVzdF90aW1l?= In-Reply-To: References: Message-ID: <20130508092341.18655d3b@shtepa.cupidplc.priv> > Для запросов обрабатываемых локейшеном empty_gif из > ngx_http_empty_gif_module в лог пишется нулевое время выполнения > запроса, точнее "0.000" > Я проверил снифером - у меня выходит, например, между tcp-пакетом > содержащим http GET и пакетом с пикселем порядка 0.02 sec, общая > продолжительность tcp-сессии - 0.048 sec, а в логах всё время нули. > > Подскажите пожалуйста, есть ли возможность логировать время выполнения > запросов для такого локейшена? Похоже на ефект от timer_resolution (http://nginx.org/ru/docs/ngx_core_module.html#timer_resolution) From zmey1992 at ya.ru Wed May 8 08:08:06 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 08 May 2013 12:08:06 +0400 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: <15710675846.20130505202257@gmail.com> References: <15710675846.20130505202257@gmail.com> Message-ID: <1370921368000486@web13h.yandex.ru> Занесите auth_basic в контекст http {}, все server{} внутри унаследуют его (только что проверил). 05.05.2013, 18:23, "psixozzz at gmail.com" : > Здравствуйте, Nginx-ru. > > Дано:     домен     с   большим   количеством  поддоменов.  Задача: > открыть  доступ  только для ограниченного круга лиц, включая мобильные > клиенты.   Крайне   желательно   ограничиться   средствами  nginx,  не > вмешиваясь   в скрипты сайта. Авторизация нужна только для того, чтобы > не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое, > как,  например,  факт  наличия  куки  у  клиента  и т.п. Никак не могу > придумать, как это реализовать. > Basic-авторизация    не   подходит,   т.к.   она   не   кроссдоменная. > Рассматривал  вариант  когда сайт не пускает никого, у кого > нет  определенной куки, а получить ее можно, зайдя на определенный урл > внутри   сайта.  Возникли  проблемы  с  внесением  изменений в текущую > конфигурацию nginx: > >  if ($cookie_edws != '1033'){ >       return 444; >  } > >  location = /auth_url { >    add_header Set-Cookie "lcid=1033;Domain=.domain.com;Path=/;Max-Age=31536000"; >    rewrite ^(.*)$ domain.com persistent; >  } > >  if (!-e $request_filename) { >       rewrite ^(.*)$ /index.php break; >  } > > Таким  образом, если физически auth_url не существует, то управление в > location  = /auth_url не попадет никогда, а всегда будет передано в if > (-e  $request_filename).  Даже  если  вмешаться в структуру сайта (что > неприемлимо)  и  создать  файл  auth_url,  то в location управление не > попадет  из-за  существования  if  ($cookie_edws != '1033'). Замкнутый > круг какой-то. > > Может многоуважаемый All подскажет как быть? > > -- > С уважением, >  Psixozzz                          mailto:psixozzz at gmail.com > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Wed May 8 08:31:32 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 09:31:32 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130507232304.GR69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> Message-ID: <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: > Hello! > > On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: > >> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >> >> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? > > При любых изменениях тела ответа, в том числе - модулем gzip, > ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, > чтобы strong etags у ответов совпадали тогда и только тогда, когда > ответы совпадают до байта. (А если ответы будет не совпадать при > одинаковых ETag'ах - это в свою очередь чревато получением > неверного суммарного ответа при комбинировании нескольких ответов > на range-запросы.) Почитать подробности можно тут (и далее по > ссылкам): > > http://tools.ietf.org/html/rfc2616#section-3.11 > Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, может в сочетании с Last-Modified? Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? > В качестве оптимизации - можно обучить nginx отделять weak etags > от strong etags, и убирать только strong. Но для начала имеет > смысл понять - надо ли оно на самом деле. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From danila at shtan.ru Wed May 8 09:27:17 2013 From: danila at shtan.ru (Danila Shtan) Date: Wed, 8 May 2013 15:27:17 +0600 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: <1370921368000486@web13h.yandex.ru> References: <15710675846.20130505202257@gmail.com> <1370921368000486@web13h.yandex.ru> Message-ID: Проблема с auth_basic не в том, как её наследовать, а в том, что на domain.com, site.domain.com, trash.domain.com пользователю придется вводить пароли отдельно. Д. 2013/5/8 Васильев "Zmey!" Олег > Занесите auth_basic в контекст http {}, все server{} внутри унаследуют его > (только что проверил). > > 05.05.2013, 18:23, "psixozzz at gmail.com" : > > Здравствуйте, Nginx-ru. > > > > Дано: домен с большим количеством поддоменов. Задача: > > открыть доступ только для ограниченного круга лиц, включая мобильные > > клиенты. Крайне желательно ограничиться средствами nginx, не > > вмешиваясь в скрипты сайта. Авторизация нужна только для того, чтобы > > не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое, > > как, например, факт наличия куки у клиента и т.п. Никак не могу > > придумать, как это реализовать. > > Basic-авторизация не подходит, т.к. она не кроссдоменная. > > Рассматривал вариант когда сайт не пускает никого, у кого > > нет определенной куки, а получить ее можно, зайдя на определенный урл > > внутри сайта. Возникли проблемы с внесением изменений в текущую > > конфигурацию nginx: > > > > if ($cookie_edws != '1033'){ > > return 444; > > } > > > > location = /auth_url { > > add_header Set-Cookie "lcid=1033;Domain=.domain.com > ;Path=/;Max-Age=31536000"; > > rewrite ^(.*)$ domain.com persistent; > > } > > > > if (!-e $request_filename) { > > rewrite ^(.*)$ /index.php break; > > } > > > > Таким образом, если физически auth_url не существует, то управление в > > location = /auth_url не попадет никогда, а всегда будет передано в if > > (-e $request_filename). Даже если вмешаться в структуру сайта (что > > неприемлимо) и создать файл auth_url, то в location управление не > > попадет из-за существования if ($cookie_edws != '1033'). Замкнутый > > круг какой-то. > > > > Может многоуважаемый All подскажет как быть? > > > > -- > > С уважением, > > Psixozzz mailto:psixozzz at gmail.com > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed May 8 09:34:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 13:34:22 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> Message-ID: <20130508093422.GV69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: > > On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: > > > Hello! > > > > On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: > > > >> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, > >> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). > >> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. > >> > >> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, > >> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. > >> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? > > > > При любых изменениях тела ответа, в том числе - модулем gzip, > > ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, > > чтобы strong etags у ответов совпадали тогда и только тогда, когда > > ответы совпадают до байта. (А если ответы будет не совпадать при > > одинаковых ETag'ах - это в свою очередь чревато получением > > неверного суммарного ответа при комбинировании нескольких ответов > > на range-запросы.) Почитать подробности можно тут (и далее по > > ссылкам): > > > > http://tools.ietf.org/html/rfc2616#section-3.11 > > > > Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, > может в сочетании с Last-Modified? В чём цель? > Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? Поддержка entity tags не имеет отношения к spdy, и появилась в nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с ним не делал. -- Maxim Dounin http://nginx.org/en/donation.html From onokonem at gmail.com Wed May 8 09:53:24 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 8 May 2013 13:53:24 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130508093422.GV69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: >> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >> может в сочетании с Last-Modified? > В чём цель? Ну вот у меня файловое хранилище отдает ETag, и это sha1 несжатого контента. Хотелось бы жать всякие js-css, и при этом оставить себе возможность отвечать 304. Вообще - что может случиться с уникальностью контента от сжатия? По-моему - ничего. Какой тогда смысл вырезать etag?.. PS Еще, конечно, хочется собирать ETag для документа, прошедшего через ssi из ETag всех включенных документов. Но это, боюсь, невозможно реализовать... From anatoly at sonru.com Wed May 8 10:18:31 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 11:18:31 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130508093422.GV69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: > Hello! > > On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: > >> >> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >> >>> Hello! >>> >>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>> >>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>> >>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>> >>> При любых изменениях тела ответа, в том числе - модулем gzip, >>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>> ответы совпадают до байта. (А если ответы будет не совпадать при >>> одинаковых ETag'ах - это в свою очередь чревато получением >>> неверного суммарного ответа при комбинировании нескольких ответов >>> на range-запросы.) Почитать подробности можно тут (и далее по >>> ссылкам): >>> >>> http://tools.ietf.org/html/rfc2616#section-3.11 >>> >> >> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >> может в сочетании с Last-Modified? > > В чём цель? Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) > >> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? > > Поддержка entity tags не имеет отношения к spdy, и появилась в > nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с > ним не делал. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Wed May 8 10:21:32 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 11:21:32 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: <97F47879-3454-4BE1-9899-EA24659696B2@sonru.com> On May 8, 2013, at 10:53 AM, Daniel Podolsky wrote: >>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>> может в сочетании с Last-Modified? >> В чём цель? > Ну вот у меня файловое хранилище отдает ETag, и это sha1 несжатого > контента. Хотелось бы жать всякие js-css, и при этом оставить себе > возможность отвечать 304. > смысл использовать эвристику браузера для статичного контента? статику не надо нагружать лишними ETag/Last-Modified, для этого лучше использовать браузерный кэш (Cache-Control) и уникальное имя, содержащее git sha1 например. > Вообще - что может случиться с уникальностью контента от сжатия? > По-моему - ничего. Какой тогда смысл вырезать etag?.. gzip изменяет размер ответа > > PS > Еще, конечно, хочется собирать ETag для документа, прошедшего через > ssi из ETag всех включенных документов. Но это, боюсь, невозможно > реализовать... > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Wed May 8 10:33:55 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 11:33:55 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: <7AEFF87F-2FCE-4085-BB23-0EEE4820994E@sonru.com> On May 8, 2013, at 11:18 AM, Anatoly Mikhailov wrote: > > On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: > >> Hello! >> >> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >> >>> >>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>> >>>> Hello! >>>> >>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>> >>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>> >>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>> >>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>> неверного суммарного ответа при комбинировании нескольких ответов >>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>> ссылкам): >>>> >>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>> >>> >>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>> может в сочетании с Last-Modified? >> >> В чём цель? > > Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), > тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) > > E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) > >> >>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >> >> Поддержка entity tags не имеет отношения к spdy, и появилась в >> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >> ним не делал. Максим, а есть возможность сказать nginx, чтобы он забыл про ETag и опять с ним ничего не делал (отдавал в backend как и до 1.3.3)? >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed May 8 10:34:43 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 14:34:43 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: <20130508103443.GY69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 01:53:24PM +0400, Daniel Podolsky wrote: > >> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, > >> может в сочетании с Last-Modified? > > В чём цель? > Ну вот у меня файловое хранилище отдает ETag, и это sha1 несжатого > контента. Хотелось бы жать всякие js-css, и при этом оставить себе > возможность отвечать 304. > > Вообще - что может случиться с уникальностью контента от сжатия? > По-моему - ничего. Какой тогда смысл вырезать etag?.. Контент сжатый и контент несжатый - это два разных контента, и тут можно использовать только weak entity tags. Ну или Last-Modified. > PS > Еще, конечно, хочется собирать ETag для документа, прошедшего через > ssi из ETag всех включенных документов. Но это, боюсь, невозможно > реализовать... ETag'и включённых документов (if any) становятся известны уже после отправки заголовков, так что опасения верные. -- Maxim Dounin http://nginx.org/en/donation.html From zmey1992 at ya.ru Wed May 8 10:36:48 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 08 May 2013 14:36:48 +0400 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: References: <15710675846.20130505202257@gmail.com> <1370921368000486@web13h.yandex.ru> Message-ID: <1296271368009408@web16f.yandex.ru> Ну, если принципиально (а автор писал, что его смущает лишь кроссдоменность), до для авторизации можно сделать отдельный server{} на IP (без домена) или даже лучше порту. Допустим, получим следующую схему: - Заходим на 1.2.3.4:1025/domain - Ставим куку - Редиректим на domain. Один из вариантов. 08.05.2013, 13:27, "Danila Shtan" : >  Проблема с auth_basic не в том, как её наследовать, а в том, что на domain.com, site.domain.com, trash.domain.com пользователю придется вводить пароли отдельно. > >  Д. > >  2013/5/8 Васильев "Zmey!" Олег >>  Занесите auth_basic в контекст http {}, все server{} внутри унаследуют его (только что проверил). >> >>  05.05.2013, 18:23, "psixozzz at gmail.com" : >>>  Здравствуйте, Nginx-ru. >>> >>>  Дано:     домен     с   большим   количеством  поддоменов.  Задача: >>>  открыть  доступ  только для ограниченного круга лиц, включая мобильные >>>  клиенты.   Крайне   желательно   ограничиться   средствами  nginx,  не >>>  вмешиваясь   в скрипты сайта. Авторизация нужна только для того, чтобы >>>  не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое, >>>  как,  например,  факт  наличия  куки  у  клиента  и т.п. Никак не могу >>>  придумать, как это реализовать. >>>  Basic-авторизация    не   подходит,   т.к.   она   не   кроссдоменная. >>>  Рассматривал  вариант  когда сайт не пускает никого, у кого >>>  нет  определенной куки, а получить ее можно, зайдя на определенный урл >>>  внутри   сайта.  Возникли  проблемы  с  внесением  изменений в текущую >>>  конфигурацию nginx: >>> >>>   if ($cookie_edws != '1033'){ >>>        return 444; >>>   } >>> >>>   location = /auth_url { >>>     add_header Set-Cookie "lcid=1033;Domain=.domain.com;Path=/;Max-Age=31536000"; >>>     rewrite ^(.*)$ domain.com persistent; >>>   } >>> >>>   if (!-e $request_filename) { >>>        rewrite ^(.*)$ /index.php break; >>>   } >>> >>>  Таким  образом, если физически auth_url не существует, то управление в >>>  location  = /auth_url не попадет никогда, а всегда будет передано в if >>>  (-e  $request_filename).  Даже  если  вмешаться в структуру сайта (что >>>  неприемлимо)  и  создать  файл  auth_url,  то в location управление не >>>  попадет  из-за  существования  if  ($cookie_edws != '1033'). Замкнутый >>>  круг какой-то. >>> >>>  Может многоуважаемый All подскажет как быть? >>> >>>  -- >>>  С уважением, >>>   Psixozzz                          mailto:psixozzz at gmail.com >>> >>>  _______________________________________________ >>>  nginx-ru mailing list >>>  nginx-ru at nginx.org >>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru >>  _______________________________________________ >>  nginx-ru mailing list >>  nginx-ru at nginx.org >>  http://mailman.nginx.org/mailman/listinfo/nginx-ru >  , >  _______________________________________________ >  nginx-ru mailing list >  nginx-ru at nginx.org >  http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed May 8 10:38:05 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 14:38:05 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: <20130508103805.GZ69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 11:18:31AM +0100, Anatoly Mikhailov wrote: > > On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: > > > Hello! > > > > On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: > > > >> > >> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: > >> > >>> Hello! > >>> > >>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: > >>> > >>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, > >>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). > >>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. > >>>> > >>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, > >>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. > >>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? > >>> > >>> При любых изменениях тела ответа, в том числе - модулем gzip, > >>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, > >>> чтобы strong etags у ответов совпадали тогда и только тогда, когда > >>> ответы совпадают до байта. (А если ответы будет не совпадать при > >>> одинаковых ETag'ах - это в свою очередь чревато получением > >>> неверного суммарного ответа при комбинировании нескольких ответов > >>> на range-запросы.) Почитать подробности можно тут (и далее по > >>> ссылкам): > >>> > >>> http://tools.ietf.org/html/rfc2616#section-3.11 > >>> > >> > >> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, > >> может в сочетании с Last-Modified? > > > > В чём цель? > > Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), > тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) > > E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) Last-Modified - как работал, так и работает. Насколько я понимаю, единственная ситуация, которая хоть как-то затронута - это когда есть только ETag (и соответственно убирается gzip-фильтром), а Last-Modified - нет совсем. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Wed May 8 10:40:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 14:40:34 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <7AEFF87F-2FCE-4085-BB23-0EEE4820994E@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <7AEFF87F-2FCE-4085-BB23-0EEE4820994E@sonru.com> Message-ID: <20130508104033.GA69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 11:33:55AM +0100, Anatoly Mikhailov wrote: [...] > >>> Кстати, до реализации SPDY все было точно так же (ETag не > >>> проксировался при Gzip)? > >> > >> Поддержка entity tags не имеет отношения к spdy, и появилась > >> в nginx 1.3.3. До этого nginx не знал про заголовок ETag и > >> ничего с ним не делал. > > Максим, а есть возможность сказать nginx, чтобы он забыл про > ETag и опять с ним ничего не делал (отдавал в backend как и до > 1.3.3)? Нет. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Wed May 8 10:49:01 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 8 May 2013 16:49:01 +0600 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: расскажите более подробно про сценарии, когда необходим именно ETag ? по моим наблюдениям большинство браузеров используют If-Not-Modified-Since, и небольшая часть - одновременно If-Not-Modified-Since и ETag. с другой стороны, если контент заведомо статический, отдаем его с "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов почти полностью. какой великий смысл в том, чтобы отдать статику, не указав при этом длинный Expire (или max-age), чтобы браузер делал лишний запрос "не обновилась ли картинка/стиль/скрипт" ? если вы добиваетесь именно "UI responsiveness", логично вообще избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это не так сложно. 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: > > On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: > >> Hello! >> >> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >> >>> >>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>> >>>> Hello! >>>> >>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>> >>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>> >>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>> >>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>> неверного суммарного ответа при комбинировании нескольких ответов >>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>> ссылкам): >>>> >>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>> >>> >>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>> может в сочетании с Last-Modified? >> >> В чём цель? > > Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), > тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) > > E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) > >> >>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >> >> Поддержка entity tags не имеет отношения к spdy, и появилась в >> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >> ним не делал. >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From onokonem at gmail.com Wed May 8 11:15:24 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 8 May 2013 15:15:24 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130508103443.GY69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> Message-ID: 2013/5/8 Maxim Dounin : > Контент сжатый и контент несжатый - это два разных контента, и тут > можно использовать только weak entity tags. Ну или Last-Modified. Сквид может обмануться? о нем я не подумал, да... тогда, может быть, дать нам настройку add_prefix_to_etag_header_on_gzip? From anatoly at sonru.com Wed May 8 11:21:41 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 12:21:41 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: On May 8, 2013, at 11:49 AM, Илья Шипицин wrote: > расскажите более подробно про сценарии, когда необходим именно ETag ? > ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом > по моим наблюдениям большинство браузеров используют > If-Not-Modified-Since, и небольшая часть - одновременно > If-Not-Modified-Since и ETag. эти вещи не жестко связаны, вы можете использовать либо то, либо другое, либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k > > с другой стороны, если контент заведомо статический, отдаем его с > "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов > почти полностью. для статики это лучший вариант, для динамики - на усмотрение > > какой великий смысл в том, чтобы отдать статику, не указав при этом > длинный Expire (или max-age), чтобы браузер делал лишний запрос "не > обновилась ли картинка/стиль/скрипт" ? никакого, статика вся должна ложиться в браузерный кэш и не привлекать эвристический анализ > > если вы добиваетесь именно "UI responsiveness", логично вообще > избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это > не так сложно. это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, что ничего нового нет > > 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: >> >> On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: >> >>> Hello! >>> >>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>> >>>> >>>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>>> >>>>> Hello! >>>>> >>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>> >>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>>> >>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>>> >>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>> ссылкам): >>>>> >>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>> >>>> >>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>>> может в сочетании с Last-Modified? >>> >>> В чём цель? >> >> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), >> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) >> >> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) >> >>> >>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >>> >>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>> ним не делал. >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/en/donation.html >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From onokonem at gmail.com Wed May 8 11:26:24 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 8 May 2013 15:26:24 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <97F47879-3454-4BE1-9899-EA24659696B2@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <97F47879-3454-4BE1-9899-EA24659696B2@sonru.com> Message-ID: > смысл использовать эвристику браузера для статичного контента? Не знаю, почему вы называете этот метод эвристикой... Но - у меня не статический контент, у меня квази-статический контент. И он не мой, а моих клиентов, и я его не во всем контролирую. Поэтому я хочу: 1) получать от браузера запрос всякий раз, когда он хочет показать мой контент пользователю 2) экономить трафик с помощью 304 > статику не надо нагружать лишними ETag/Last-Modified, для этого лучше использовать > браузерный кэш (Cache-Control) и уникальное имя, содержащее git sha1 например. у меня есть некий css, который в ключен в миллиона 3-4 html документов. уникальное имя потребует при обновлении этого css обновления и этих 3-4 миллионов, что, к сожалению неприемлемо. From anatoly at sonru.com Wed May 8 11:31:11 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 12:31:11 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <97F47879-3454-4BE1-9899-EA24659696B2@sonru.com> Message-ID: <6382B8E9-51C8-48ED-BDEC-D92B04DE3E3E@sonru.com> On May 8, 2013, at 12:26 PM, Daniel Podolsky wrote: >> смысл использовать эвристику браузера для статичного контента? > Не знаю, почему вы называете этот метод эвристикой... > > Но - у меня не статический контент, у меня квази-статический контент. > И он не мой, а моих клиентов, и я его не во всем контролирую. > > Поэтому я хочу: > 1) получать от браузера запрос всякий раз, когда он хочет показать мой > контент пользователю > 2) экономить трафик с помощью 304 > >> статику не надо нагружать лишними ETag/Last-Modified, для этого лучше использовать >> браузерный кэш (Cache-Control) и уникальное имя, содержащее git sha1 например. > у меня есть некий css, который в ключен в миллиона 3-4 html > документов. уникальное имя потребует при обновлении этого css > обновления и этих 3-4 миллионов, что, к сожалению неприемлемо. да, в этом случае ETag и Last-Modified для статики - подходящее решение, только не забывайте, что Nginx 1.3.3 откусывает ETag в сочетании с gzip on > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Wed May 8 11:50:45 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 8 May 2013 17:50:45 +0600 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: это бред, бред и еще сто раз бред. если вы точно уверены, что контент кешируемый, добавляете на него Expire (или max-age, как нравится) и у браузера уже есть копия контента, про которую он точно знает, что она актуальна. в этом случае браузер начинает отрисовывать страницу сразу же. если вы знаете, что контент неизменяемый, но не отдали Expire, то у браузера есть некая копия контента, про которую он не уверен. Он сделает ЛИШНИЙ запрос (это время) с заголовком If-Modified-Since/If-None-Match и только после этого начнет отрисовывать страницу. и в каком месте здесь "UI responsiveness" ? чем гоняться за ETag-ами, лучше сделать правильный Expire. генерация уникальных имен для CSS делается на стороне приложения. это проработанная тема, если у вас Ruby On Rails, например, вот так http://code.google.com/p/bundle-fu/ да, идея простая - уменьшить количество запросов и сделать уникальный хеш для статических сборок. необязательно вообще всё навешивать на nginx. 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov написал: > > On May 8, 2013, at 11:49 AM, Илья Шипицин wrote: > >> расскажите более подробно про сценарии, когда необходим именно ETag ? >> > > ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем > и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом > >> по моим наблюдениям большинство браузеров используют >> If-Not-Modified-Since, и небольшая часть - одновременно >> If-Not-Modified-Since и ETag. > > эти вещи не жестко связаны, вы можете использовать либо то, либо другое, > либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k > >> >> с другой стороны, если контент заведомо статический, отдаем его с >> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов >> почти полностью. > > для статики это лучший вариант, для динамики - на усмотрение > >> >> какой великий смысл в том, чтобы отдать статику, не указав при этом >> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не >> обновилась ли картинка/стиль/скрипт" ? > > никакого, статика вся должна ложиться в браузерный кэш и не привлекать > эвристический анализ > >> >> если вы добиваетесь именно "UI responsiveness", логично вообще >> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это >> не так сложно. > > это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, > что ничего нового нет > >> >> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: >>> >>> On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: >>> >>>> Hello! >>>> >>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>>> >>>>> >>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>>> >>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>>>> >>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>>>> >>>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>>> ссылкам): >>>>>> >>>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>>> >>>>> >>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>>>> может в сочетании с Last-Modified? >>>> >>>> В чём цель? >>> >>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), >>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) >>> >>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) >>> >>>> >>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >>>> >>>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>>> ним не делал. >>>> >>>> -- >>>> Maxim Dounin >>>> http://nginx.org/en/donation.html >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From anatoly at sonru.com Wed May 8 11:58:41 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 12:58:41 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> Message-ID: <79F70726-E04B-464F-9EA2-8E587B735A5B@sonru.com> On May 8, 2013, at 12:50 PM, Илья Шипицин wrote: > это бред, бред и еще сто раз бред. ответ в пустоту, не забывайте указывать контекст > > если вы точно уверены, что контент кешируемый, добавляете на него > Expire (или max-age, как нравится) и у браузера уже есть копия > контента, про которую он точно знает, что она актуальна. в этом случае > браузер начинает отрисовывать страницу сразу же. > > если вы знаете, что контент неизменяемый, но не отдали Expire, то у > браузера есть некая копия контента, про которую он не уверен. Он > сделает ЛИШНИЙ запрос (это время) с заголовком > If-Modified-Since/If-None-Match и только после этого начнет > отрисовывать страницу. > > и в каком месте здесь "UI responsiveness" ? > > > чем гоняться за ETag-ами, лучше сделать правильный Expire. > Expire уже везде правильный > > > генерация уникальных имен для CSS делается на стороне приложения. это > проработанная тема, если у вас Ruby On Rails, например, вот так > http://code.google.com/p/bundle-fu/ Assets Pipeline делает тоже самое > > > да, идея простая - уменьшить количество запросов и сделать уникальный > хеш для статических сборок. > > > необязательно вообще всё навешивать на nginx. > > > > 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov написал: >> >> On May 8, 2013, at 11:49 AM, Илья Шипицин wrote: >> >>> расскажите более подробно про сценарии, когда необходим именно ETag ? >>> >> >> ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем >> и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом >> >>> по моим наблюдениям большинство браузеров используют >>> If-Not-Modified-Since, и небольшая часть - одновременно >>> If-Not-Modified-Since и ETag. >> >> эти вещи не жестко связаны, вы можете использовать либо то, либо другое, >> либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k >> >>> >>> с другой стороны, если контент заведомо статический, отдаем его с >>> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов >>> почти полностью. >> >> для статики это лучший вариант, для динамики - на усмотрение >> >>> >>> какой великий смысл в том, чтобы отдать статику, не указав при этом >>> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не >>> обновилась ли картинка/стиль/скрипт" ? >> >> никакого, статика вся должна ложиться в браузерный кэш и не привлекать >> эвристический анализ >> >>> >>> если вы добиваетесь именно "UI responsiveness", логично вообще >>> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это >>> не так сложно. >> >> это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, >> что ничего нового нет >> >>> >>> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: >>>> >>>> On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: >>>> >>>>> Hello! >>>>> >>>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>>>> >>>>>> >>>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>>>> >>>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>>>>> >>>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>>>>> >>>>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>>>> ссылкам): >>>>>>> >>>>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>>>> >>>>>> >>>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>>>>> может в сочетании с Last-Modified? >>>>> >>>>> В чём цель? >>>> >>>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), >>>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) >>>> >>>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) >>>> >>>>> >>>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >>>>> >>>>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>>>> ним не делал. >>>>> >>>>> -- >>>>> Maxim Dounin >>>>> http://nginx.org/en/donation.html >>>>> >>>>> _______________________________________________ >>>>> nginx-ru mailing list >>>>> nginx-ru at nginx.org >>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Wed May 8 12:08:33 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 8 May 2013 18:08:33 +0600 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <79F70726-E04B-464F-9EA2-8E587B735A5B@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <79F70726-E04B-464F-9EA2-8E587B735A5B@sonru.com> Message-ID: Если Expire уже правильный, то для динамического контента вы все равно сгенерируете страницу (независимо от ETag-ов), а за статическим контентом браузер второй раз не придет. то есть проблем нет вообще никаких. наличие ETag-а (или его отсутствие) роли не играют. да, компоновщиков статики много. и они делают примерно одно и то же. делают весьма хорошо. 8 мая 2013 г., 17:58 пользователь Anatoly Mikhailov написал: > > On May 8, 2013, at 12:50 PM, Илья Шипицин wrote: > >> это бред, бред и еще сто раз бред. > > ответ в пустоту, не забывайте указывать контекст > >> >> если вы точно уверены, что контент кешируемый, добавляете на него >> Expire (или max-age, как нравится) и у браузера уже есть копия >> контента, про которую он точно знает, что она актуальна. в этом случае >> браузер начинает отрисовывать страницу сразу же. >> >> если вы знаете, что контент неизменяемый, но не отдали Expire, то у >> браузера есть некая копия контента, про которую он не уверен. Он >> сделает ЛИШНИЙ запрос (это время) с заголовком >> If-Modified-Since/If-None-Match и только после этого начнет >> отрисовывать страницу. >> >> и в каком месте здесь "UI responsiveness" ? >> >> >> чем гоняться за ETag-ами, лучше сделать правильный Expire. >> > > Expire уже везде правильный > >> >> >> генерация уникальных имен для CSS делается на стороне приложения. это >> проработанная тема, если у вас Ruby On Rails, например, вот так >> http://code.google.com/p/bundle-fu/ > > Assets Pipeline делает тоже самое > >> >> >> да, идея простая - уменьшить количество запросов и сделать уникальный >> хеш для статических сборок. >> >> >> необязательно вообще всё навешивать на nginx. >> >> >> >> 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov написал: >>> >>> On May 8, 2013, at 11:49 AM, Илья Шипицин wrote: >>> >>>> расскажите более подробно про сценарии, когда необходим именно ETag ? >>>> >>> >>> ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем >>> и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом >>> >>>> по моим наблюдениям большинство браузеров используют >>>> If-Not-Modified-Since, и небольшая часть - одновременно >>>> If-Not-Modified-Since и ETag. >>> >>> эти вещи не жестко связаны, вы можете использовать либо то, либо другое, >>> либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k >>> >>>> >>>> с другой стороны, если контент заведомо статический, отдаем его с >>>> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов >>>> почти полностью. >>> >>> для статики это лучший вариант, для динамики - на усмотрение >>> >>>> >>>> какой великий смысл в том, чтобы отдать статику, не указав при этом >>>> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не >>>> обновилась ли картинка/стиль/скрипт" ? >>> >>> никакого, статика вся должна ложиться в браузерный кэш и не привлекать >>> эвристический анализ >>> >>>> >>>> если вы добиваетесь именно "UI responsiveness", логично вообще >>>> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это >>>> не так сложно. >>> >>> это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, >>> что ничего нового нет >>> >>>> >>>> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: >>>>> >>>>> On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>>>>> >>>>>>> >>>>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>>>>>> >>>>>>>> Hello! >>>>>>>> >>>>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>>>>> >>>>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>>>>>> >>>>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>>>>>> >>>>>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>>>>> ссылкам): >>>>>>>> >>>>>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>>>>> >>>>>>> >>>>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>>>>>> может в сочетании с Last-Modified? >>>>>> >>>>>> В чём цель? >>>>> >>>>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), >>>>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) >>>>> >>>>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) >>>>> >>>>>> >>>>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >>>>>> >>>>>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>>>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>>>>> ним не делал. >>>>>> >>>>>> -- >>>>>> Maxim Dounin >>>>>> http://nginx.org/en/donation.html >>>>>> >>>>>> _______________________________________________ >>>>>> nginx-ru mailing list >>>>>> nginx-ru at nginx.org >>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>>> >>>>> _______________________________________________ >>>>> nginx-ru mailing list >>>>> nginx-ru at nginx.org >>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed May 8 14:29:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 18:29:34 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> Message-ID: <20130508142934.GB69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 03:15:24PM +0400, Daniel Podolsky wrote: > 2013/5/8 Maxim Dounin : > > Контент сжатый и контент несжатый - это два разных контента, и тут > > можно использовать только weak entity tags. Ну или Last-Modified. > Сквид может обмануться? о нем я не подумал, да... > > тогда, может быть, дать нам настройку add_prefix_to_etag_header_on_gzip? Префикс - неправильно, по результатам gzip'ования может получиться разный контент, в зависимости от настроек или даже тайминга ответа бекенда. В gzip-фильтре можно сделать две вещи: 1) Не трогать weak etag'и вообще. 2) Превращать strong etag'и в weak etag'и. Но, опять же, хотелось бы всё-таки какого-то вменяемого описания use case'а, в котором это нужно. Потому как в большинстве известных мне случаев - есть Last-Modified, который weak etag с успехом заменяет. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Wed May 8 14:53:04 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 8 May 2013 15:53:04 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130508142934.GB69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> <20130508142934.GB69760@mdounin.ru> Message-ID: <34B1259E-05DD-45B2-B3D3-86EC4F3DD2F4@sonru.com> On May 8, 2013, at 3:29 PM, Maxim Dounin wrote: > Hello! > > On Wed, May 08, 2013 at 03:15:24PM +0400, Daniel Podolsky wrote: > >> 2013/5/8 Maxim Dounin : >>> Контент сжатый и контент несжатый - это два разных контента, и тут >>> можно использовать только weak entity tags. Ну или Last-Modified. >> Сквид может обмануться? о нем я не подумал, да... >> >> тогда, может быть, дать нам настройку add_prefix_to_etag_header_on_gzip? > > Префикс - неправильно, по результатам gzip'ования может > получиться разный контент, в зависимости от настроек или даже > тайминга ответа бекенда. > > В gzip-фильтре можно сделать две вещи: > > 1) Не трогать weak etag'и вообще. > > 2) Превращать strong etag'и в weak etag'и. > > Но, опять же, хотелось бы всё-таки какого-то вменяемого описания > use case'а, в котором это нужно. Потому как в большинстве > известных мне случаев - есть Last-Modified, который weak etag с > успехом заменяет. Только что проверил сочетание Last-Modified и ETag со включенным gzip, похоже, эта связка явно препятствует очистке ETag при отдаче ответа браузеру и 304 Not Modified срабатывает как надо > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed May 8 15:03:26 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 19:03:26 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <34B1259E-05DD-45B2-B3D3-86EC4F3DD2F4@sonru.com> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> <20130508142934.GB69760@mdounin.ru> <34B1259E-05DD-45B2-B3D3-86EC4F3DD2F4@sonru.com> Message-ID: <20130508150326.GC69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 03:53:04PM +0100, Anatoly Mikhailov wrote: > > On May 8, 2013, at 3:29 PM, Maxim Dounin wrote: > > > Hello! > > > > On Wed, May 08, 2013 at 03:15:24PM +0400, Daniel Podolsky wrote: > > > >> 2013/5/8 Maxim Dounin : > >>> Контент сжатый и контент несжатый - это два разных контента, и тут > >>> можно использовать только weak entity tags. Ну или Last-Modified. > >> Сквид может обмануться? о нем я не подумал, да... > >> > >> тогда, может быть, дать нам настройку add_prefix_to_etag_header_on_gzip? > > > > Префикс - неправильно, по результатам gzip'ования может > > получиться разный контент, в зависимости от настроек или даже > > тайминга ответа бекенда. > > > > В gzip-фильтре можно сделать две вещи: > > > > 1) Не трогать weak etag'и вообще. > > > > 2) Превращать strong etag'и в weak etag'и. > > > > Но, опять же, хотелось бы всё-таки какого-то вменяемого описания > > use case'а, в котором это нужно. Потому как в большинстве > > известных мне случаев - есть Last-Modified, который weak etag с > > успехом заменяет. > > Только что проверил сочетание Last-Modified и ETag со включенным gzip, > похоже, эта связка явно препятствует очистке ETag при отдаче ответа > браузеру и 304 Not Modified срабатывает как надо Очистке ETag - ничего не препятствует. Просто Last-Modified - не чистится, чистится только ETag. Соответственно браузеры используют Last-Modified, и 304 нормально возвращается. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Wed May 8 17:03:25 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 8 May 2013 21:03:25 +0400 Subject: resumable upload In-Reply-To: <51895802.2080008@grid.net.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> Message-ID: <20130508170324.GD69760@mdounin.ru> Hello! On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: > On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: > > > >On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: > > > >>On 29.03.2013 17:02, Валентин Бартенев wrote: > >>>Просто когда дело заходит о том, что на грамотную реализацию и последующую > >>>поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен > >>>кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то > >>>оно и нужно было. > >>Большинство вопрошающих вполне устраивал upload_module. > >> > >>P.S. Пожалуй, это тупиковая ветвь дискуссии. > > > >тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку > >уже как полгода. > > Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. > > Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы > спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё > будет". > > Однако, я считатю, что подобный ответ не соответствует моему уровню. > Предлагаемая бизнес-модель не работает, я проверил это на > собственном опыте. В то же время, поддерживать этот модуль на > собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос > из nginx (sic!). > > Nginx меня многому научил, и у меня появилось множество идей того, > как всевозможные вещи реализовать на более высоком уровне, гибче и > доступнее. Более того, часть из своих гипотез я уже успел проверить. > Однако, я пока не уверен, что это выльется в конкретный проект. > > Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, > несмотря на то, что в nginx достаточно было бы поправить несколько > строк. Валерий, если есть конкретные предложения, какие именно строки поправить в самом nginx'е - пожалуйста, выскажи их. Мне, к сожалению, не кажется, что дело ограничется парой строчек. Чтобы нормально работать с телом запроса - нужен, в первую очередь, механизм для этого, чтобы не приходилось, как это сейчас сделано, переизобретать чтение тела запроса в каждом модуле, которому что-то с телом надо сделать. Я потратил некоторое время на создание такого механизма в рамках работы над поддержкой chunked-запросов, но a) upload модуль придётся заметно переписать, чтобы использовать этот механизм и б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно было нормально работать из сторонних модулей. Если вдруг есть желание заняться/посмотреть - то патч можно взять тут: http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html Из известных проблем - оно несовместимо со spdy, у которого, всилу особенностей протокола, совсем своя логика чтения тела запроса. -- Maxim Dounin http://nginx.org/en/donation.html From valery+nginxru at grid.net.ru Wed May 8 20:13:05 2013 From: valery+nginxru at grid.net.ru (Valery Kholodkov) Date: Wed, 08 May 2013 22:13:05 +0200 Subject: resumable upload In-Reply-To: <20130508170324.GD69760@mdounin.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> Message-ID: <518AB1D1.60802@grid.net.ru> On 05/08/2013 07:03 PM, Maxim Dounin wrote: > Hello! > > On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: > >> On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: >>> >>> On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: >>> >>>> On 29.03.2013 17:02, Валентин Бартенев wrote: >>>>> Просто когда дело заходит о том, что на грамотную реализацию и последующую >>>>> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >>>>> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >>>>> оно и нужно было. >>>> Большинство вопрошающих вполне устраивал upload_module. >>>> >>>> P.S. Пожалуй, это тупиковая ветвь дискуссии. >>> >>> тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку >>> уже как полгода. >> >> Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. >> >> Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы >> спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё >> будет". >> >> Однако, я считатю, что подобный ответ не соответствует моему уровню. >> Предлагаемая бизнес-модель не работает, я проверил это на >> собственном опыте. В то же время, поддерживать этот модуль на >> собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос >> из nginx (sic!). >> >> Nginx меня многому научил, и у меня появилось множество идей того, >> как всевозможные вещи реализовать на более высоком уровне, гибче и >> доступнее. Более того, часть из своих гипотез я уже успел проверить. >> Однако, я пока не уверен, что это выльется в конкретный проект. >> >> Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, >> несмотря на то, что в nginx достаточно было бы поправить несколько >> строк. > > Валерий, если есть конкретные предложения, какие именно строки > поправить в самом nginx'е - пожалуйста, выскажи их. Чтобы работало достаточно вернуть переменную to_write в ngx_http_request_body_t. > Мне, к сожалению, не кажется, что дело ограничется парой строчек. > Чтобы нормально работать с телом запроса - нужен, в первую > очередь, механизм для этого, чтобы не приходилось, как это сейчас > сделано, переизобретать чтение тела запроса в каждом модуле, > которому что-то с телом надо сделать. > Я потратил некоторое время на создание такого механизма в рамках > работы над поддержкой chunked-запросов, но a) upload модуль > придётся заметно переписать, чтобы использовать этот механизм и > б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно > было нормально работать из сторонних модулей. > > Если вдруг есть желание заняться/посмотреть - то патч можно взять > тут: > > http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html У меня самого где-то валяется подобный кусок кода. Проблема заключается в HTTP pipelining. Я уже два года назад просил механизм возвращения буферов в заголовок запроса. Без этого нельзя выйти из ситуации, когда за телом запроса незамедлительно следует часть заголовка следующего запроса. > Из известных проблем - оно несовместимо со spdy, у которого, всилу > особенностей протокола, совсем своя логика чтения тела запроса. -- Best regards, Valery Kholodkov From onokonem at gmail.com Wed May 8 21:19:32 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 9 May 2013 01:19:32 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: <20130508142934.GB69760@mdounin.ru> References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> <20130508142934.GB69760@mdounin.ru> Message-ID: > Префикс - неправильно, по результатам gzip'ования может > получиться разный контент, в зависимости от настроек или даже > тайминга ответа бекенда. Я поразмыслил над этим утверждением, и оно не кажется мне верным :) Контент в зависимости от тайминга ответа бекенда, может быть, и получится разный, но будет он вполне эквивалентный. Настройки gzip - дело другое, но тут надо просто дать нам возможность указывать этот самый префикс самим. Тогда при изменении настроек мы будем его менять, и все у нас будет хорошо. Но, наверное, Last-Modified действительно заменяет weak etag. У меня довольно часто меняется Last-Modified без изменения собственно контента, и мне об этом известно. Но, скорее всего, тут зряшного трафика получается на копейку, или меньше, так что и возиться смысла нет. From anatoly at sonru.com Thu May 9 00:13:19 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 9 May 2013 01:13:19 +0100 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <79F70726-E04B-464F-9EA2-8E587B735A5B@sonru.com> Message-ID: <84A5EBCE-65C2-4C6C-B0DF-B75C0C237F1A@sonru.com> On 08.05.2013, at 13:08, Илья Шипицин wrote: > Если Expire уже правильный, то для динамического контента вы все равно > сгенерируете страницу (независимо от ETag-ов), а за статическим > контентом браузер второй раз не придет. > > то есть проблем нет вообще никаких. наличие ETag-а (или его > отсутствие) роли не играют. что вы так привязались к Expire, если тред о ConditionalGet. > > да, компоновщиков статики много. и они делают примерно одно и то же. > делают весьма хорошо. а что тут можно придумать нового, конечно, одно и тоже. > > 8 мая 2013 г., 17:58 пользователь Anatoly Mikhailov написал: >> >> On May 8, 2013, at 12:50 PM, Илья Шипицин wrote: >> >>> это бред, бред и еще сто раз бред. >> >> ответ в пустоту, не забывайте указывать контекст >> >>> >>> если вы точно уверены, что контент кешируемый, добавляете на него >>> Expire (или max-age, как нравится) и у браузера уже есть копия >>> контента, про которую он точно знает, что она актуальна. в этом случае >>> браузер начинает отрисовывать страницу сразу же. >>> >>> если вы знаете, что контент неизменяемый, но не отдали Expire, то у >>> браузера есть некая копия контента, про которую он не уверен. Он >>> сделает ЛИШНИЙ запрос (это время) с заголовком >>> If-Modified-Since/If-None-Match и только после этого начнет >>> отрисовывать страницу. >>> >>> и в каком месте здесь "UI responsiveness" ? >>> >>> >>> чем гоняться за ETag-ами, лучше сделать правильный Expire. >> >> Expire уже везде правильный >> >>> >>> >>> генерация уникальных имен для CSS делается на стороне приложения. это >>> проработанная тема, если у вас Ruby On Rails, например, вот так >>> http://code.google.com/p/bundle-fu/ >> >> Assets Pipeline делает тоже самое >> >>> >>> >>> да, идея простая - уменьшить количество запросов и сделать уникальный >>> хеш для статических сборок. >>> >>> >>> необязательно вообще всё навешивать на nginx. >>> >>> >>> >>> 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov написал: >>>> >>>> On May 8, 2013, at 11:49 AM, Илья Шипицин wrote: >>>> >>>>> расскажите более подробно про сценарии, когда необходим именно ETag ? >>>> >>>> ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем >>>> и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом >>>> >>>>> по моим наблюдениям большинство браузеров используют >>>>> If-Not-Modified-Since, и небольшая часть - одновременно >>>>> If-Not-Modified-Since и ETag. >>>> >>>> эти вещи не жестко связаны, вы можете использовать либо то, либо другое, >>>> либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k >>>> >>>>> >>>>> с другой стороны, если контент заведомо статический, отдаем его с >>>>> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов >>>>> почти полностью. >>>> >>>> для статики это лучший вариант, для динамики - на усмотрение >>>> >>>>> >>>>> какой великий смысл в том, чтобы отдать статику, не указав при этом >>>>> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не >>>>> обновилась ли картинка/стиль/скрипт" ? >>>> >>>> никакого, статика вся должна ложиться в браузерный кэш и не привлекать >>>> эвристический анализ >>>> >>>>> >>>>> если вы добиваетесь именно "UI responsiveness", логично вообще >>>>> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это >>>>> не так сложно. >>>> >>>> это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, >>>> что ничего нового нет >>>> >>>>> >>>>> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov написал: >>>>>> >>>>>> On May 8, 2013, at 10:34 AM, Maxim Dounin wrote: >>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>>>>>> >>>>>>>> >>>>>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin wrote: >>>>>>>> >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>>>>>> >>>>>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в конфигурации Nginx, >>>>>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном ответе от бэкэнда (Unicorn). >>>>>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные параметры на это не влияют. >>>>>>>>>> >>>>>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет заголовок ETag к каждому ответу, >>>>>>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать gzip. >>>>>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые заголовки? >>>>>>>>> >>>>>>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>>>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>>>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>>>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>>>>>> ссылкам): >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>>>>> >>>>>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять ETag, пришедший от бэкэнда, >>>>>>>> может в сочетании с Last-Modified? >>>>>>> >>>>>>> В чём цель? >>>>>> >>>>>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит данные (идеально - из браузерного кэша), >>>>>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело запроса от бэкэнда (fresh_when/stale в Rack) >>>>>> >>>>>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно перестали работать как раз после Nginx 1.3.3 :) >>>>>> >>>>>>> >>>>>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался при Gzip)? >>>>>>> >>>>>>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>>>>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>>>>>> ним не делал. >>>>>>> >>>>>>> -- >>>>>>> Maxim Dounin >>>>>>> http://nginx.org/en/donation.html >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nginx-ru mailing list >>>>>>> nginx-ru at nginx.org >>>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>>>> >>>>>> _______________________________________________ >>>>>> nginx-ru mailing list >>>>>> nginx-ru at nginx.org >>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>>> _______________________________________________ >>>>> nginx-ru mailing list >>>>> nginx-ru at nginx.org >>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu May 9 08:49:28 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 9 May 2013 12:49:28 +0400 Subject: =?UTF-8?Q?Re=3A_Gzip_=D0=B8_ETag?= In-Reply-To: References: <9A4028A1-F7F5-452A-AE20-1F87B217829B@sonru.com> <20130507232304.GR69760@mdounin.ru> <2F125AEF-2B48-4BF2-A05C-2F5FC1D37B59@sonru.com> <20130508093422.GV69760@mdounin.ru> <20130508103443.GY69760@mdounin.ru> <20130508142934.GB69760@mdounin.ru> Message-ID: <20130509084928.GH69760@mdounin.ru> Hello! On Thu, May 09, 2013 at 01:19:32AM +0400, Daniel Podolsky wrote: > > Префикс - неправильно, по результатам gzip'ования может > > получиться разный контент, в зависимости от настроек или даже > > тайминга ответа бекенда. > Я поразмыслил над этим утверждением, и оно не кажется мне верным :) > > Контент в зависимости от тайминга ответа бекенда, может быть, и > получится разный, но будет он вполне эквивалентный. Я стесняюсь спросить - что в этом предложении понимается под словами "разный" и "эквивалентный"? С точки зрения "octet equality" (т.е. возможности использования strong etags) - контент может быть другой при использовании deflate(Z_SYNC_FLUSH), которое будет, например, в случае proxy_buffering off. > Настройки gzip - дело другое, но тут надо просто дать нам возможность > указывать этот самый префикс самим. Тогда при изменении настроек мы > будем его менять, и все у нас будет хорошо. > > Но, наверное, Last-Modified действительно заменяет weak etag. > > У меня довольно часто меняется Last-Modified без изменения собственно > контента, и мне об этом известно. Но, скорее всего, тут зряшного > трафика получается на копейку, или меньше, так что и возиться смысла > нет. Ну как бы я о том и говорю: заморочиться поддержкой weak etags можно, но Last-Modified всё равно есть чуть менее, чем всегда, и смысла в этом немного. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Thu May 9 10:21:23 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Thu, 9 May 2013 11:21:23 +0100 Subject: resumable upload In-Reply-To: <518AB1D1.60802@grid.net.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> Message-ID: <9444FCFA-A69A-478A-BDFC-CAC21CE2B497@sonru.com> On May 8, 2013, at 9:13 PM, Valery Kholodkov wrote: > On 05/08/2013 07:03 PM, Maxim Dounin wrote: >> Hello! >> >> On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: >> >>> On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: >>>> >>>> On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: >>>> >>>>> On 29.03.2013 17:02, Валентин Бартенев wrote: >>>>>> Просто когда дело заходит о том, что на грамотную реализацию и последующую >>>>>> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >>>>>> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >>>>>> оно и нужно было. >>>>> Большинство вопрошающих вполне устраивал upload_module. >>>>> >>>>> P.S. Пожалуй, это тупиковая ветвь дискуссии. >>>> >>>> тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку >>>> уже как полгода. >>> >>> Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. >>> >>> Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы >>> спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё >>> будет". >>> >>> Однако, я считатю, что подобный ответ не соответствует моему уровню. >>> Предлагаемая бизнес-модель не работает, я проверил это на >>> собственном опыте. В то же время, поддерживать этот модуль на >>> собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос >>> из nginx (sic!). >>> >>> Nginx меня многому научил, и у меня появилось множество идей того, >>> как всевозможные вещи реализовать на более высоком уровне, гибче и >>> доступнее. Более того, часть из своих гипотез я уже успел проверить. >>> Однако, я пока не уверен, что это выльется в конкретный проект. >>> >>> Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, >>> несмотря на то, что в nginx достаточно было бы поправить несколько >>> строк. >> >> Валерий, если есть конкретные предложения, какие именно строки >> поправить в самом nginx'е - пожалуйста, выскажи их. > > Чтобы работало достаточно вернуть переменную to_write в ngx_http_request_body_t. > >> Мне, к сожалению, не кажется, что дело ограничется парой строчек. >> Чтобы нормально работать с телом запроса - нужен, в первую >> очередь, механизм для этого, чтобы не приходилось, как это сейчас >> сделано, переизобретать чтение тела запроса в каждом модуле, >> которому что-то с телом надо сделать. > >> Я потратил некоторое время на создание такого механизма в рамках >> работы над поддержкой chunked-запросов, но a) upload модуль >> придётся заметно переписать, чтобы использовать этот механизм и >> б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно >> было нормально работать из сторонних модулей. >> >> Если вдруг есть желание заняться/посмотреть - то патч можно взять >> тут: >> >> http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html > > У меня самого где-то валяется подобный кусок кода. Проблема заключается в HTTP pipelining. Я уже два года назад просил механизм возвращения буферов в заголовок запроса. Без этого нельзя выйти из ситуации, когда за телом запроса незамедлительно следует часть заголовка следующего запроса. не проверял, но есть мнение, что один сторонний патч nginx-upload-module работает с nginx 1.4.0 https://github.com/vkholodkov/nginx-upload-module/issues/45 > >> Из известных проблем - оно несовместимо со spdy, у которого, всилу >> особенностей протокола, совсем своя логика чтения тела запроса. > > -- > Best regards, > Valery Kholodkov > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu May 9 11:54:26 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 9 May 2013 15:54:26 +0400 Subject: resumable upload In-Reply-To: <518AB1D1.60802@grid.net.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> Message-ID: <20130509115425.GI69760@mdounin.ru> Hello! On Wed, May 08, 2013 at 10:13:05PM +0200, Valery Kholodkov wrote: > On 05/08/2013 07:03 PM, Maxim Dounin wrote: > >Hello! > > > >On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: > > > >>On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: > >>> > >>>On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: > >>> > >>>>On 29.03.2013 17:02, Валентин Бартенев wrote: > >>>>>Просто когда дело заходит о том, что на грамотную реализацию и последующую > >>>>>поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен > >>>>>кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то > >>>>>оно и нужно было. > >>>>Большинство вопрошающих вполне устраивал upload_module. > >>>> > >>>>P.S. Пожалуй, это тупиковая ветвь дискуссии. > >>> > >>>тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку > >>>уже как полгода. > >> > >>Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. > >> > >>Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы > >>спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё > >>будет". > >> > >>Однако, я считатю, что подобный ответ не соответствует моему уровню. > >>Предлагаемая бизнес-модель не работает, я проверил это на > >>собственном опыте. В то же время, поддерживать этот модуль на > >>собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос > >>из nginx (sic!). > >> > >>Nginx меня многому научил, и у меня появилось множество идей того, > >>как всевозможные вещи реализовать на более высоком уровне, гибче и > >>доступнее. Более того, часть из своих гипотез я уже успел проверить. > >>Однако, я пока не уверен, что это выльется в конкретный проект. > >> > >>Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, > >>несмотря на то, что в nginx достаточно было бы поправить несколько > >>строк. > > > >Валерий, если есть конкретные предложения, какие именно строки > >поправить в самом nginx'е - пожалуйста, выскажи их. > > Чтобы работало достаточно вернуть переменную to_write в > ngx_http_request_body_t. Если я правильно понимаю, это - не чтобы работало, а чтобы собиралось. В 1.3.9 появилась поддержка Transfer-Encoding chunked, и если такой запрос попадёт в location с upload - всё сломается. > >Мне, к сожалению, не кажется, что дело ограничется парой строчек. > >Чтобы нормально работать с телом запроса - нужен, в первую > >очередь, механизм для этого, чтобы не приходилось, как это сейчас > >сделано, переизобретать чтение тела запроса в каждом модуле, > >которому что-то с телом надо сделать. > > >Я потратил некоторое время на создание такого механизма в рамках > >работы над поддержкой chunked-запросов, но a) upload модуль > >придётся заметно переписать, чтобы использовать этот механизм и > >б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно > >было нормально работать из сторонних модулей. > > > >Если вдруг есть желание заняться/посмотреть - то патч можно взять > >тут: > > > >http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html > > У меня самого где-то валяется подобный кусок кода. Проблема > заключается в HTTP pipelining. Я уже два года назад просил механизм > возвращения буферов в заголовок запроса. Без этого нельзя выйти из > ситуации, когда за телом запроса незамедлительно следует часть > заголовка следующего запроса. Проблемы HTTP pipelining'а - это то, что должен решать (и решает) сам nginx в рамках функций чтения тела запроса. Фильтрам тела запроса достаются уже прочитанные от клиента данные. > >Из известных проблем - оно несовместимо со spdy, у которого, всилу > >особенностей протокола, совсем своя логика чтения тела запроса. > > -- > Best regards, > Valery Kholodkov > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From valery+nginxru at grid.net.ru Fri May 10 15:16:10 2013 From: valery+nginxru at grid.net.ru (Valery Kholodkov) Date: Fri, 10 May 2013 17:16:10 +0200 Subject: resumable upload In-Reply-To: <20130509115425.GI69760@mdounin.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> Message-ID: <518D0F3A.70507@grid.net.ru> On 05/09/2013 01:54 PM, Maxim Dounin wrote: > Hello! > > On Wed, May 08, 2013 at 10:13:05PM +0200, Valery Kholodkov wrote: > >> On 05/08/2013 07:03 PM, Maxim Dounin wrote: >>> Hello! >>> >>> On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: >>> >>>> On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: >>>>> >>>>> On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: >>>>> >>>>>> On 29.03.2013 17:02, Валентин Бартенев wrote: >>>>>>> Просто когда дело заходит о том, что на грамотную реализацию и последующую >>>>>>> поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен >>>>>>> кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то >>>>>>> оно и нужно было. >>>>>> Большинство вопрошающих вполне устраивал upload_module. >>>>>> >>>>>> P.S. Пожалуй, это тупиковая ветвь дискуссии. >>>>> >>>>> тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку >>>>> уже как полгода. >>>> >>>> Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. >>>> >>>> Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы >>>> спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё >>>> будет". >>>> >>>> Однако, я считатю, что подобный ответ не соответствует моему уровню. >>>> Предлагаемая бизнес-модель не работает, я проверил это на >>>> собственном опыте. В то же время, поддерживать этот модуль на >>>> собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос >>>> из nginx (sic!). >>>> >>>> Nginx меня многому научил, и у меня появилось множество идей того, >>>> как всевозможные вещи реализовать на более высоком уровне, гибче и >>>> доступнее. Более того, часть из своих гипотез я уже успел проверить. >>>> Однако, я пока не уверен, что это выльется в конкретный проект. >>>> >>>> Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, >>>> несмотря на то, что в nginx достаточно было бы поправить несколько >>>> строк. >>> >>> Валерий, если есть конкретные предложения, какие именно строки >>> поправить в самом nginx'е - пожалуйста, выскажи их. >> >> Чтобы работало достаточно вернуть переменную to_write в >> ngx_http_request_body_t. > > Если я правильно понимаю, это - не чтобы работало, а чтобы > собиралось. В 1.3.9 появилась поддержка Transfer-Encoding > chunked, и если такой запрос попадёт в location с upload - всё > сломается. Ты предлагал высказать мои предложения относительно того, что нужно исправить, -- я высказал. У меня нет ни времени ни желания отслеживать что и как вы там меняете и подстраиваться под эти изменения. >>> Мне, к сожалению, не кажется, что дело ограничется парой строчек. >>> Чтобы нормально работать с телом запроса - нужен, в первую >>> очередь, механизм для этого, чтобы не приходилось, как это сейчас >>> сделано, переизобретать чтение тела запроса в каждом модуле, >>> которому что-то с телом надо сделать. >> >>> Я потратил некоторое время на создание такого механизма в рамках >>> работы над поддержкой chunked-запросов, но a) upload модуль >>> придётся заметно переписать, чтобы использовать этот механизм и >>> б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно >>> было нормально работать из сторонних модулей. >>> >>> Если вдруг есть желание заняться/посмотреть - то патч можно взять >>> тут: >>> >>> http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html >> >> У меня самого где-то валяется подобный кусок кода. Проблема >> заключается в HTTP pipelining. Я уже два года назад просил механизм >> возвращения буферов в заголовок запроса. Без этого нельзя выйти из >> ситуации, когда за телом запроса незамедлительно следует часть >> заголовка следующего запроса. > > Проблемы HTTP pipelining'а - это то, что должен решать (и решает) > сам nginx в рамках функций чтения тела запроса. Фильтрам тела > запроса достаются уже прочитанные от клиента данные. Так где API для этого? Какие функции нужно крутить, куда вставлять свои хэндлеры? >>> Из известных проблем - оно несовместимо со spdy, у которого, всилу >>> особенностей протокола, совсем своя логика чтения тела запроса. -- Best regards, Valery Kholodkov From mdounin at mdounin.ru Fri May 10 16:45:57 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 10 May 2013 20:45:57 +0400 Subject: resumable upload In-Reply-To: <518D0F3A.70507@grid.net.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> <518D0F3A.70507@grid.net.ru> Message-ID: <20130510164557.GL69760@mdounin.ru> Hello! On Fri, May 10, 2013 at 05:16:10PM +0200, Valery Kholodkov wrote: > On 05/09/2013 01:54 PM, Maxim Dounin wrote: > >Hello! > > > >On Wed, May 08, 2013 at 10:13:05PM +0200, Valery Kholodkov wrote: > > > >>On 05/08/2013 07:03 PM, Maxim Dounin wrote: > >>>Hello! > >>> > >>>On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote: > >>> > >>>>On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote: > >>>>> > >>>>>On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski wrote: > >>>>> > >>>>>>On 29.03.2013 17:02, Валентин Бартенев wrote: > >>>>>>>Просто когда дело заходит о том, что на грамотную реализацию и последующую > >>>>>>>поддержку этого кода нужно потратить сколько-то человеко-часов, которые должен > >>>>>>>кто-то оплатить, то часто выясняется, что большинству вопрошающих не очень то > >>>>>>>оно и нужно было. > >>>>>>Большинство вопрошающих вполне устраивал upload_module. > >>>>>> > >>>>>>P.S. Пожалуй, это тупиковая ветвь дискуссии. > >>>>> > >>>>>тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на поддержку > >>>>>уже как полгода. > >>>> > >>>>Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию. > >>>> > >>>>Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы > >>>>спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё > >>>>будет". > >>>> > >>>>Однако, я считатю, что подобный ответ не соответствует моему уровню. > >>>>Предлагаемая бизнес-модель не работает, я проверил это на > >>>>собственном опыте. В то же время, поддерживать этот модуль на > >>>>собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос > >>>>из nginx (sic!). > >>>> > >>>>Nginx меня многому научил, и у меня появилось множество идей того, > >>>>как всевозможные вещи реализовать на более высоком уровне, гибче и > >>>>доступнее. Более того, часть из своих гипотез я уже успел проверить. > >>>>Однако, я пока не уверен, что это выльется в конкретный проект. > >>>> > >>>>Поэтому, как видите, ситуация не может сдвинутся с мертвой точки, > >>>>несмотря на то, что в nginx достаточно было бы поправить несколько > >>>>строк. > >>> > >>>Валерий, если есть конкретные предложения, какие именно строки > >>>поправить в самом nginx'е - пожалуйста, выскажи их. > >> > >>Чтобы работало достаточно вернуть переменную to_write в > >>ngx_http_request_body_t. > > > >Если я правильно понимаю, это - не чтобы работало, а чтобы > >собиралось. В 1.3.9 появилась поддержка Transfer-Encoding > >chunked, и если такой запрос попадёт в location с upload - всё > >сломается. > > Ты предлагал высказать мои предложения относительно того, что нужно > исправить, -- я высказал. У меня нет ни времени ни желания > отслеживать что и как вы там меняете и подстраиваться под эти > изменения. Fair enough. > >>>Мне, к сожалению, не кажется, что дело ограничется парой строчек. > >>>Чтобы нормально работать с телом запроса - нужен, в первую > >>>очередь, механизм для этого, чтобы не приходилось, как это сейчас > >>>сделано, переизобретать чтение тела запроса в каждом модуле, > >>>которому что-то с телом надо сделать. > >> > >>>Я потратил некоторое время на создание такого механизма в рамках > >>>работы над поддержкой chunked-запросов, но a) upload модуль > >>>придётся заметно переписать, чтобы использовать этот механизм и > >>>б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно > >>>было нормально работать из сторонних модулей. > >>> > >>>Если вдруг есть желание заняться/посмотреть - то патч можно взять > >>>тут: > >>> > >>>http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html > >> > >>У меня самого где-то валяется подобный кусок кода. Проблема > >>заключается в HTTP pipelining. Я уже два года назад просил механизм > >>возвращения буферов в заголовок запроса. Без этого нельзя выйти из > >>ситуации, когда за телом запроса незамедлительно следует часть > >>заголовка следующего запроса. > > > >Проблемы HTTP pipelining'а - это то, что должен решать (и решает) > >сам nginx в рамках функций чтения тела запроса. Фильтрам тела > >запроса достаются уже прочитанные от клиента данные. > > Так где API для этого? Какие функции нужно крутить, куда вставлять > свои хэндлеры? Патч по ссылке выше как раз это API добавляет. Интерфейс - подобен body-фильтрам ответа: добавляешь обработчик в цепочку фильтров (сохранив/поставив ngx_http_top_request_body_filter), по мере прихода данных от клиента - его вызовут с цепочкой прочитанных буферов. -- Maxim Dounin http://nginx.org/en/donation.html From valery+nginxru at grid.net.ru Fri May 10 17:08:39 2013 From: valery+nginxru at grid.net.ru (Valery Kholodkov) Date: Fri, 10 May 2013 19:08:39 +0200 Subject: resumable upload In-Reply-To: <20130510164557.GL69760@mdounin.ru> References: <201303290030.17949.vbart@nginx.com> <515508B4.9040202@bestmx.ru> <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> <518D0F3A.70507@grid.net.ru> <20130510164557.GL69760@mdounin.ru> Message-ID: <518D2997.4060806@grid.net.ru> On 05/10/2013 06:45 PM, Maxim Dounin wrote: >> Так где API для этого? Какие функции нужно крутить, куда вставлять >> свои хэндлеры? > > Патч по ссылке выше как раз это API добавляет. Интерфейс - > подобен body-фильтрам ответа: добавляешь обработчик в цепочку > фильтров (сохранив/поставив ngx_http_top_request_body_filter), > по мере прихода данных от клиента - его вызовут с цепочкой > прочитанных буферов. Они интегрирован или нет? -- Best regards, Valery Kholodkov From motienko at gmail.com Fri May 10 17:09:08 2013 From: motienko at gmail.com (Oleg Motienko) Date: Fri, 10 May 2013 21:09:08 +0400 Subject: =?UTF-8?B?UmU6INGP0L3QtNC10LrRgS3Qv9GA0L7QutGB0Lg=?= In-Reply-To: References: <133168612.20121116215051@softsearch.ru> <1985791021.20121117010135@mtu-net.ru> Message-ID: у яндекса добавились адреса из подсети 141.8.189.0/24 2013/4/11 Oleg Motienko > > У нас для этого дела DNAT поднят по списку подсетей на отдельный порт > и дальше уже конфиг примерно такой > > #yandex turbo > set_real_ip_from 5.45.192.0/24; > > # Opera Turbo proxies > set_real_ip_from 91.203.96.0/24; > set_real_ip_from 94.246.126.0/23; > set_real_ip_from 195.189.142.0/23; > # other turbo > set_real_ip_from 64.255.180.0/24; > set_real_ip_from 80.239.242.0/23; > set_real_ip_from 80.232.117.0/24; > set_real_ip_from 59.151.106.240/28; > > real_ip_header X-Forwarded-For; > > > > 2012/11/17 Andrey Repin : > > Здравствуйте, Уважаемый(-ая, -ое) Aleksandr Sytar! > > > >>> Похоже, что у яндекса по аналогии с Оперой появились прокси-сервера > >>> для своего браузера. Никто не знает ip-шки этих проксей и заголовки, > >>> где реальный ip передаётся? > > > > > > AS> На презенации они рассказывали что используют технологию Opera Turbo - > > AS> соотвественно и их же сервера > > > > Используют технологию =/= используют сервера. > > Опера как раз зарабатывает на продаже этих сервисов. > > > > > > -- > > С уважением > > > > Andrey Repin (hell-for-yahoo at umail.ru) суббота, 17.11.2012, <01:00> > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Regards, > Oleg -- Regards, Oleg From mdounin at mdounin.ru Sat May 11 14:41:55 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 11 May 2013 18:41:55 +0400 Subject: resumable upload In-Reply-To: <518D2997.4060806@grid.net.ru> References: <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> <518D0F3A.70507@grid.net.ru> <20130510164557.GL69760@mdounin.ru> <518D2997.4060806@grid.net.ru> Message-ID: <20130511144155.GN69760@mdounin.ru> Hello! On Fri, May 10, 2013 at 07:08:39PM +0200, Valery Kholodkov wrote: > On 05/10/2013 06:45 PM, Maxim Dounin wrote: > >>Так где API для этого? Какие функции нужно крутить, куда вставлять > >>свои хэндлеры? > > > >Патч по ссылке выше как раз это API добавляет. Интерфейс - > >подобен body-фильтрам ответа: добавляешь обработчик в цепочку > >фильтров (сохранив/поставив ngx_http_top_request_body_filter), > >по мере прихода данных от клиента - его вызовут с цепочкой > >прочитанных буферов. > > Они интегрирован или нет? Он экспериментальный и не закоммичен. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Sun May 12 18:33:02 2013 From: nginx-forum at nginx.us (stitrace) Date: Sun, 12 May 2013 14:33:02 -0400 Subject: PURGE Message-ID: Добрый день! Поясните пожалуйста работу PURGE модуля. Что происходит когда очистили кэш для страницы? Запросы от пользователей ожидают генерацию нового кэша, а генерируется он по одному запросу, или все запросы для этого урла начинают проходить на бэкэнд, пока не будет сгенерирован новый кэш? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239102,239102#msg-239102 From nginx-forum at nginx.us Sun May 12 19:59:55 2013 From: nginx-forum at nginx.us (r3l0c) Date: Sun, 12 May 2013 15:59:55 -0400 Subject: =?UTF-8?B?0JrRgNGP0LrQvtC30Y/QsdGLINCyINC60LXRiNC40YDQvtCy0LDQvdC90YvRhSA=?= =?UTF-8?B?0YTQsNC50LvQsNGFIHByb3h5IHN0b3Jl?= Message-ID: <51cfe76d28a7d11d6591d3487eca9b9a.NginxMailingListRussian@forum.nginx.org> Такая проблмка - запилил проксирование + кеширование при помощи proxy_store, все работает норм, нужная статика не дергается с бэкэнда, но через некоторое время в некоторых файлах изменяется содержание - сплошные крякозябы =), вот мой конфиг, кто сталкивался с подобной проблемой?) Выбрал такой способ кеширования - нет нужды кешировать странички, просто достаточно было не дергать кучу файлов с бэкэнда, + кеш перемешивался, тк я одним конфигом хотел проксировать и кешировать все сайтенги, и если на одном сайте в корне лежал image.jpg, то если он закешировался на одном сайте - он отдается на других сайтах при совпадении имени, было решено сбрасывать все в отдельные папки при помощи $host server { server_name *.ru; proxy_ignore_client_abort off; access_log off; location ~* \.(jpg|jpeg|gif|png|ico|bmp|js|css|txt|pdf|rar|zip)$ { root /var/www/data/$host; open_file_cache_errors off; error_page 404 = @static; } location @static { internal; proxy_set_header Host $host; proxy_pass $scheme://192.168.1.192:$server_port; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /var/www/data/$host; root /var/www/data/$host; } location / { proxy_intercept_errors on; proxy_pass $scheme://192.168.1.192:$server_port; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 30s; proxy_send_timeout 30s; proxy_read_timeout 30s; proxy_buffer_size 64k; proxy_buffers 16 32k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 1m; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239103,239103#msg-239103 From mdounin at mdounin.ru Mon May 13 07:15:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 13 May 2013 11:15:07 +0400 Subject: =?UTF-8?B?UmU6INCa0YDRj9C60L7Qt9GP0LHRiyDQsiDQutC10YjQuNGA0L7QstCw0L3QvdGL?= =?UTF-8?B?0YUg0YTQsNC50LvQsNGFIHByb3h5IHN0b3Jl?= In-Reply-To: <51cfe76d28a7d11d6591d3487eca9b9a.NginxMailingListRussian@forum.nginx.org> References: <51cfe76d28a7d11d6591d3487eca9b9a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130513071507.GY69760@mdounin.ru> Hello! On Sun, May 12, 2013 at 03:59:55PM -0400, r3l0c wrote: > Такая проблмка - запилил проксирование + кеширование при помощи proxy_store, > все работает норм, нужная статика не дергается с бэкэнда, но через некоторое > время в некоторых файлах изменяется содержание - сплошные крякозябы =), вот > мой конфиг, кто сталкивался с подобной проблемой?) Видимо, у вас бекенды отдают сжатый контент. Решений два - отучить бекенды отдавать сжатый контент, или убедить его, что клиенты ничего не поддерживают, написав proxy_set_header Accept-Encoding ""; в конфиге nginx'а. > Выбрал такой способ кеширования - нет нужды кешировать странички, просто > достаточно было не дергать кучу файлов с бэкэнда, + кеш перемешивался, тк я > одним конфигом хотел проксировать и кешировать все сайтенги, и если на одном > сайте в корне лежал image.jpg, то если он закешировался на одном сайте - он > отдается на других сайтах при совпадении имени, было решено сбрасывать все в > отдельные папки при помощи $host А на proxy_cache смотреть не пробовали? Если нужно именно кеширование, а не зеркало полностью статического и никогда не меняющегося контента - то proxy_cache более удобное решение. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon May 13 11:32:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 13 May 2013 15:32:59 +0400 Subject: nginx-1.2.9 Message-ID: <20130513113259.GK69760@mdounin.ru> Изменения в nginx 1.2.9 13.05.2013 *) Безопасность: содержимое памяти рабочего процесса могло быть отправлено клиенту, если HTTP-бэкенд возвращал специально созданный ответ (CVE-2013-2070); ошибка появилась в 1.1.4. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon May 13 11:33:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 13 May 2013 15:33:41 +0400 Subject: nginx security advisory (CVE-2013-2070) Message-ID: <20130513113341.GO69760@mdounin.ru> Hello! Была обнаружена связанная с CVE-2013-2028 проблема безопасности, затрагивающая некоторые предыдущие версии nginx при использовании proxy_pass к недоверенным HTTP-серверам. Проблема может приводить к отказу в обслуживании или к отправке клиенту содержимого памяти рабочего процесса, если бэкенд вернёт специально созданный ответ. Проблеме подвержены версии nginx 1.1.4 - 1.2.8, 1.3.0 - 1.4.0. Проблема уже исправлена в nginx 1.5.0, 1.4.1. Для исправления проблемы в устаревшей ветке 1.2.x выпущена версия 1.2.9. Патч для nginx 1.3.9 - 1.4.0 тот же, что и для CVE-2013-2028: http://nginx.org/download/patch.2013.chunked.txt Патч для более старых версий nginx (1.1.4 - 1.2.8, 1.3.0 - 1.3.8): http://nginx.org/download/patch.2013.proxy.txt -- Maxim Dounin http://nginx.org/en/donation.html From n.g.i.n.x.e.r at gmail.com Mon May 13 12:00:55 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Mon, 13 May 2013 16:00:55 +0400 Subject: =?UTF-8?B?0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC90LAg0LzQvtCx0LjQu9GM?= =?UTF-8?B?0L3Rg9GOINCy0LXRgNGB0LjRjiDRgdCw0LnRgtCw?= Message-ID: Создал карту агентов. Nginx правильно разделяет мобильные устройства и не мобильные, но есть одно но. Для мобильных устройств есть возможность попасть на полную версию сайта при определенной переменной в запросе. т.е., допустим, клиент приходит на сайт site.ru с мобильного устройства и его перекидывает сразу на m.site.ru, это нормальная ситуация. а на сайте стоит ссылка site.ru/?nomobile и перейдя по ней клиент не должен снова перейти на m.site.ru, а видеть полную версию сайта Вопрос - как учесть эту переменную в конфиге Nginx? -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Mon May 13 12:08:47 2013 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Mon, 13 May 2013 16:08:47 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0YHQsNC50YLQsA==?= In-Reply-To: References: Message-ID: Мы используем куукиз. 13 мая 2013 г., 16:00 пользователь Роман написал: > Создал карту агентов. > Nginx правильно разделяет мобильные устройства и не мобильные, но есть > одно но. > Для мобильных устройств есть возможность попасть на полную версию сайта > при определенной переменной в запросе. > > т.е., допустим, клиент приходит на сайт site.ru с мобильного устройства и > его перекидывает сразу на m.site.ru, это нормальная ситуация. > а на сайте стоит ссылка site.ru/?nomobile и перейдя по ней клиент не > должен снова перейти на m.site.ru, а видеть полную версию сайта > > Вопрос - как учесть эту переменную в конфиге Nginx? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Панфилов Михаил -------------- next part -------------- An HTML attachment was scrubbed... URL: From sytar.alex at gmail.com Mon May 13 12:29:13 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Mon, 13 May 2013 16:29:13 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0YHQsNC50YLQsA==?= In-Reply-To: References: Message-ID: 13 мая 2013 г., 16:00 пользователь Роман написал: > Создал карту агентов. > Nginx правильно разделяет мобильные устройства и не мобильные, но есть > одно но. > Для мобильных устройств есть возможность попасть на полную версию сайта > при определенной переменной в запросе. > > т.е., допустим, клиент приходит на сайт site.ru с мобильного устройства и > его перекидывает сразу на m.site.ru, это нормальная ситуация. > а на сайте стоит ссылка site.ru/?nomobile и перейдя по ней клиент не > должен снова перейти на m.site.ru, а видеть полную версию сайта > > Вопрос - как учесть эту переменную в конфиге Nginx? > Если вы делаете разделение через map - соответственно нужно эту переменную (arg_nomobile, например) запихнуть в map -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.g.i.n.x.e.r at gmail.com Mon May 13 12:50:35 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Mon, 13 May 2013 16:50:35 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0YHQsNC50YLQsA==?= In-Reply-To: References: Message-ID: А как я ее заихну в карту, если карта строится на переменной $http_user_agent? 13 мая 2013 г., 16:29 пользователь Aleksandr Sytar написал: > > > > 13 мая 2013 г., 16:00 пользователь Роман написал: > >> Создал карту агентов. >> >> Nginx правильно разделяет мобильные устройства и не мобильные, но есть >> одно но. >> Для мобильных устройств есть возможность попасть на полную версию сайта >> при определенной переменной в запросе. >> >> т.е., допустим, клиент приходит на сайт site.ru с мобильного устройства >> и его перекидывает сразу на m.site.ru, это нормальная ситуация. >> а на сайте стоит ссылка site.ru/?nomobile и перейдя по ней клиент не >> должен снова перейти на m.site.ru, а видеть полную версию сайта >> >> Вопрос - как учесть эту переменную в конфиге Nginx? >> > > Если вы делаете разделение через map - соответственно нужно эту переменную > (arg_nomobile, например) запихнуть в map > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.ye at mail.ru Mon May 13 16:53:23 2013 From: artem.ye at mail.ru (=?koi8-r?B?4dLUxc0=?=) Date: Mon, 13 May 2013 19:53:23 +0300 Subject: nginx + phpmyadmin alias Message-ID: <007501ce4ffa$624fd360$26ef7a20$@ye@mail.ru> Здравствуйте. Объясните пожалуйста почему мой Nginx возвращает ошибку 404 при обращении к /phpmyadmin. Сайт на opencart лежит в /usr/local/www/upload/ Сюда же сделана символическая ссылка на phpMyAdmin, который находится в /usr/local/www. Вот конфиг: server { listen XXX.XXX.XXX.XXX:80; server_name localhost; root /usr/local/www/upload/; index index.php index.html; location / { index index.php; try_files $uri @opencart; } location @opencart { rewrite ^/(.+)$ /index.php?_route_=$1 last; } location /admin { index index.php; } location /phpMyAdmin { index index.php; } location /phpmyadmin(.*)$ { rewrite ^/(.*)$ /phpMyAdmin/index.php$1 last; } if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?_route_=$1 last; } location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_param REDIRECT_STATUS 200; fastcgi_read_timeout 3600; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/local/www/nginx-dist; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From psixozzz at gmail.com Mon May 13 16:55:27 2013 From: psixozzz at gmail.com (psixozzz at gmail.com) Date: Mon, 13 May 2013 22:55:27 +0600 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: <1296271368009408@web16f.yandex.ru> References: <15710675846.20130505202257@gmail.com> <1370921368000486@web13h.yandex.ru> <1296271368009408@web16f.yandex.ru> Message-ID: <908701210.20130513225527@gmail.com> Здравствуйте, Васильев. Вы писали 8 мая 2013 г., 16:36:48: > Ну, если принципиально (а автор писал, что его смущает лишь кроссдоменность), до для авторизации можно сделать > отдельный server{} на IP (без домена) или даже лучше порту. Допустим, получим следующую схему: > - Заходим на 1.2.3.4:1025/domain > - Ставим куку > - Редиректим на domain. > Один из вариантов. Не получится. Не примет браузер куку на левый домен. Даже если повесить отдельный сервер на ip (без домена). только что проверил: server { listen [ip]:123; root /home/mob/; index index.html; location = / { add_header Set-Cookie "edws=1033; expires=Wed, 21-Aug-2014 16:49:59 GMT; path=/; domain=.domain.tld"; rewrite ^(.*)$ http://domain.tld permanent; } } server { ... if ($cookie_edws != '1033'){ return 444; } ... } > 08.05.2013, 13:27, "Danila Shtan" : >>  Проблема с auth_basic не в том, как её наследовать, а в том, что на domain.com, site.domain.com, trash.domain.com пользователю придется вводить пароли отдельно. >> >>  Д. >> >>  2013/5/8 Васильев "Zmey!" Олег >>>  Занесите auth_basic в контекст http {}, все server{} внутри унаследуют его (только что проверил). >>> >>>  05.05.2013, 18:23, "psixozzz at gmail.com" : >>>>  Здравствуйте, Nginx-ru. >>>> >>>>  Дано:     домен     с   большим   количеством  поддоменов.  Задача: >>>>  открыть  доступ  только для ограниченного круга лиц, включая мобильные >>>>  клиенты.   Крайне   желательно   ограничиться   средствами  nginx,  не >>>>  вмешиваясь   в скрипты сайта. Авторизация нужна только для того, чтобы >>>>  не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое, >>>>  как,  например,  факт  наличия  куки  у  клиента  и т.п. Никак не могу >>>>  придумать, как это реализовать. >>>>  Basic-авторизация    не   подходит,   т.к.   она   не   кроссдоменная. >>>>  Рассматривал  вариант  когда сайт не пускает никого, у кого >>>>  нет  определенной куки, а получить ее можно, зайдя на определенный урл >>>>  внутри   сайта.  Возникли  проблемы  с  внесением  изменений в текущую >>>>  конфигурацию nginx: >>>> >>>>   if ($cookie_edws != '1033'){ >>>>        return 444; >>>>   } >>>> >>>>   location = /auth_url { >>>>     add_header Set-Cookie "lcid=1033;Domain=.domain.com;Path=/;Max-Age=31536000"; >>>>     rewrite ^(.*)$ domain.com persistent; >>>>   } >>>> >>>>   if (!-e $request_filename) { >>>>        rewrite ^(.*)$ /index.php break; >>>>   } >>>> >>>>  Таким  образом, если физически auth_url не существует, то управление в >>>>  location  = /auth_url не попадет никогда, а всегда будет передано в if >>>>  (-e  $request_filename).  Даже  если  вмешаться в структуру сайта (что >>>>  неприемлимо)  и  создать  файл  auth_url,  то в location управление не >>>>  попадет  из-за  существования  if  ($cookie_edws != '1033'). Замкнутый >>>>  круг какой-то. >>>> >>>>  Может многоуважаемый All подскажет как быть? >>>> >>>>  -- >>>>  С уважением, >>>>   Psixozzz                          mailto:psixozzz at gmail.com -- С уважением, Вадим mailto:psixozzz at gmail.com From psixozzz at gmail.com Mon May 13 16:57:32 2013 From: psixozzz at gmail.com (psixozzz at gmail.com) Date: Mon, 13 May 2013 22:57:32 +0600 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0YHQsNC50YLQsA==?= In-Reply-To: References: Message-ID: <697915142.20130513225732@gmail.com> Здравствуйте, Роман. Простите за ффтопик, но не могли бы вы поделиться конфигом определения мобильности клиента? Можно в личную почту. Благодарю заранее! Вы писали 13 мая 2013 г., 18:00:55: > Создал карту агентов. > Nginx правильно разделяет мобильные устройства и не мобильные, но есть одно но. > Для мобильных устройств есть возможность попасть на полную версию сайта при определенной переменной в запросе. > т.е., допустим, клиент приходит на сайт site.ru с мобильного устройства и его перекидывает сразу на m.site.ru, это нормальная ситуация. > а на сайте стоит ссылка site.ru/?nomobile и перейдя по ней клиент не должен снова перейти на m.site.ru, а видеть полную версию сайта > > Вопрос - как учесть эту переменную в конфиге Nginx? -- С уважением, Вадим mailto:psixozzz at gmail.com From nginx-forum at nginx.us Mon May 13 18:15:53 2013 From: nginx-forum at nginx.us (ast) Date: Mon, 13 May 2013 14:15:53 -0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L7QsdC4?= =?UTF-8?B?0LvRjNC90YPRjiDQstC10YDRgdC40Y4g0YHQsNC50YLQsA==?= In-Reply-To: <697915142.20130513225732@gmail.com> References: <697915142.20130513225732@gmail.com> Message-ID: http://detectmobilebrowsers.com/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239133,239154#msg-239154 From postmaster at softsearch.ru Mon May 13 20:38:58 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 May 2013 00:38:58 +0400 Subject: =?UTF-8?B?UmVbMl06INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC80L4=?= =?UTF-8?B?0LHQuNC70YzQvdGD0Y4g0LLQtdGA0YHQuNGOINGB0LDQudGC0LA=?= In-Reply-To: References: Message-ID: <109259490.20130514003858@softsearch.ru> Здравствуйте, Роман. Сделайте второй map{} на параметр в аргументах, потом через set склейте обе переменные в одну строку и по ней третий map, который уже выдаст нужную переменную. -- С уважением, Михаил mailto:postmaster at softsearch.ru From tetsio.nainn at gmail.com Tue May 14 00:59:49 2013 From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=) Date: Tue, 14 May 2013 10:59:49 +1000 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: <908701210.20130513225527@gmail.com> References: <15710675846.20130505202257@gmail.com> <1370921368000486@web13h.yandex.ru> <1296271368009408@web16f.yandex.ru> <908701210.20130513225527@gmail.com> Message-ID: if (!-e $request_filename) { rewrite ^(.*)$ /index.php break; } мне не совсем понятно в каком контексте данный фрагмент. если в location, то можно попробовать, наверное вынести location = /auth_url { add_header Set-Cookie "lcid=1033;Domain=.domain.com; Path=/;Max-Age=31536000"; rewrite ^(.*)$ domain.com persistent; } выше, а если нет, то директивы if перенести внутрь location / {, а location = /auth_url оставить в контексте server 14 мая 2013 г., 2:55 пользователь написал: > Здравствуйте, Васильев. > > Вы писали 8 мая 2013 г., 16:36:48: > > > Ну, если принципиально (а автор писал, что его смущает лишь > кроссдоменность), до для авторизации можно сделать > > отдельный server{} на IP (без домена) или даже лучше порту. Допустим, > получим следующую схему: > > - Заходим на 1.2.3.4:1025/domain > > - Ставим куку > > - Редиректим на domain. > > > Один из вариантов. > > Не получится. Не примет браузер куку на левый домен. Даже если повесить > отдельный сервер на ip (без домена). только что > проверил: > > server { > listen [ip]:123; > > root /home/mob/; > index index.html; > > location = / { > add_header Set-Cookie "edws=1033; expires=Wed, 21-Aug-2014 16:49:59 > GMT; path=/; domain=.domain.tld"; > rewrite ^(.*)$ http://domain.tld permanent; > } > } > > server { > > ... > > if ($cookie_edws != '1033'){ > return 444; > } > > ... > } > > > 08.05.2013, 13:27, "Danila Shtan" : > > >> Проблема с auth_basic не в том, как её наследовать, а в том, что на > domain.com, site.domain.com, trash.domain.com пользователю придется > вводить пароли отдельно. > >> > >> Д. > >> > >> 2013/5/8 Васильев "Zmey!" Олег > >>> Занесите auth_basic в контекст http {}, все server{} внутри > унаследуют его (только что проверил). > >>> > >>> 05.05.2013, 18:23, "psixozzz at gmail.com" : > >>>> Здравствуйте, Nginx-ru. > >>>> > >>>> Дано: домен с большим количеством поддоменов. Задача: > >>>> открыть доступ только для ограниченного круга лиц, включая > мобильные > >>>> клиенты. Крайне желательно ограничиться средствами nginx, > не > >>>> вмешиваясь в скрипты сайта. Авторизация нужна только для того, > чтобы > >>>> не могли зайти люди "с улицы". Т.е. вполне подойдет что-то > слабенькое, > >>>> как, например, факт наличия куки у клиента и т.п. Никак не > могу > >>>> придумать, как это реализовать. > >>>> Basic-авторизация не подходит, т.к. она не > кроссдоменная. > >>>> Рассматривал вариант когда сайт не пускает никого, у кого > >>>> нет определенной куки, а получить ее можно, зайдя на определенный > урл > >>>> внутри сайта. Возникли проблемы с внесением изменений в > текущую > >>>> конфигурацию nginx: > >>>> > >>>> if ($cookie_edws != '1033'){ > >>>> return 444; > >>>> } > >>>> > >>>> location = /auth_url { > >>>> add_header Set-Cookie "lcid=1033;Domain=.domain.com > ;Path=/;Max-Age=31536000"; > >>>> rewrite ^(.*)$ domain.com persistent; > >>>> } > >>>> > >>>> if (!-e $request_filename) { > >>>> rewrite ^(.*)$ /index.php break; > >>>> } > >>>> > >>>> Таким образом, если физически auth_url не существует, то управление > в > >>>> location = /auth_url не попадет никогда, а всегда будет передано в > if > >>>> (-e $request_filename). Даже если вмешаться в структуру сайта > (что > >>>> неприемлимо) и создать файл auth_url, то в location управление > не > >>>> попадет из-за существования if ($cookie_edws != '1033'). > Замкнутый > >>>> круг какой-то. > >>>> > >>>> Может многоуважаемый All подскажет как быть? > >>>> > >>>> -- > >>>> С уважением, > >>>> Psixozzz mailto:psixozzz at gmail.com > > > -- > С уважением, > Вадим mailto:psixozzz at gmail.com > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С ув. М.А. Мохначевский Отдел системного администрирования ООО "Компания "СахаИнтернет НТ" к.т. (4112)219711 доб. 927 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dedukhin at mail.ru Tue May 14 05:56:11 2013 From: dedukhin at mail.ru (Dmitry Dedukhin) Date: Tue, 14 May 2013 09:56:11 +0400 Subject: resumable upload In-Reply-To: <20130511144155.GN69760@mdounin.ru> References: <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> <518D0F3A.70507@grid.net.ru> <20130510164557.GL69760@mdounin.ru> <518D2997.4060806@grid.net.ru> <20130511144155.GN69760@mdounin.ru> Message-ID: <5191D1FB.4010101@mail.ru> 11.05.2013 18:41, Maxim Dounin пишет: > Hello! > > On Fri, May 10, 2013 at 07:08:39PM +0200, Valery Kholodkov wrote: > >> On 05/10/2013 06:45 PM, Maxim Dounin wrote: >>>> Так где API для этого? Какие функции нужно крутить, куда вставлять >>>> свои хэндлеры? >>> Патч по ссылке выше как раз это API добавляет. Интерфейс - >>> подобен body-фильтрам ответа: добавляешь обработчик в цепочку >>> фильтров (сохранив/поставив ngx_http_top_request_body_filter), >>> по мере прихода данных от клиента - его вызовут с цепочкой >>> прочитанных буферов. >> Они интегрирован или нет? > Он экспериментальный и не закоммичен. Всем доброго дня. Коллеги. Сложилась не очень приятная для многих ситуация в связи с upload-модулем и его неработоспособностью в свежих версиях nginx. В частности мы используем модуль в продакшене практически с самого появления модуля, и уже более двух лет используем его фичу resumable upload. На наших нагрузках использование модуля более чем оправдано, также как и оправдано использование дозагрузки в связи с большими размерами загружаемых файлов. Я сильно опасаюсь, что когда политика нашей компании вынудит обновиться до свежей версии nginx, у меня не будет никакой замены для upload-модуля (client_body_in_file_only ни разу не полноценная замена). Поэтому, думаю многие были бы рады услышать ответ Nginx Inc. по поводу дальнейшей судьбы этого модуля, и request body-фильтров в частности, т.к. насколько я понимаю именно с их помощью можно будет легально реализовать такой же функционал. From postmaster at softsearch.ru Tue May 14 06:01:44 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 May 2013 10:01:44 +0400 Subject: resumable upload In-Reply-To: <5191D1FB.4010101@mail.ru> References: <201303291702.14246.vbart@nginx.com> <5155EDCD.20102@bestmx.ru> <9CEAD2FD-1F6F-49B4-AC02-347146BEA4F3@sonru.com> <51895802.2080008@grid.net.ru> <20130508170324.GD69760@mdounin.ru> <518AB1D1.60802@grid.net.ru> <20130509115425.GI69760@mdounin.ru> <518D0F3A.70507@grid.net.ru> <20130510164557.GL69760@mdounin.ru> <518D2997.4060806@grid.net.ru> <20130511144155.GN69760@mdounin.ru> <5191D1FB.4010101@mail.ru> Message-ID: <9310393640.20130514100144@softsearch.ru> Здравствуйте, Dmitry. > Сложилась не очень приятная для многих ситуация в связи с > upload-модулем и его неработоспособностью в свежих версиях nginx. > В частности мы используем модуль в продакшене практически с самого > появления модуля, и уже более двух лет используем его фичу resumable > upload. На наших нагрузках использование модуля более чем оправдано, > также как и оправдано использование дозагрузки в связи с большими > размерами загружаемых файлов. > Я сильно опасаюсь, что когда политика нашей компании вынудит > обновиться до свежей версии nginx, у меня не будет никакой замены > для upload-модуля (client_body_in_file_only ни разу не полноценная > замена). > Поэтому, думаю многие были бы рады услышать ответ Nginx Inc. по > поводу дальнейшей судьбы этого модуля, и request body-фильтров в > частности, т.к. насколько я понимаю именно с их помощью можно будет > легально реализовать такой же функционал. Если так сильно нужен модуль, то почему бы не проспонсировать его доработку? У меня была подобная ситуация с самописным модулем и всё прекрасно разрешилось. -- С уважением, Михаил mailto:postmaster at softsearch.ru From chipitsine at gmail.com Tue May 14 08:24:31 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 May 2013 14:24:31 +0600 Subject: =?UTF-8?B?0L/QsNGC0Ycg0LTQu9GPIENvbm5lY3Rpb246IEtlZXAtQWxpdmU=?= Message-ID: Добрый день! предлагаю оставить только "Connection: Keep-Alive" в случае HTTP/1.0 во всех остальных случаях предлагаю не отдавать никакой Connection. Аналогичным образом работает IIS. еще есть вопрос, в каких условиях должен срабатывать код if (clcf->keepalive_header) { len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; } в файле src/http/ngx_http_header_filter_module.c, не нашел, где задается условие clcf->keepalive_header Илья Шипицин -------------- next part -------------- A non-text attachment was scrubbed... Name: keepalive.patch Type: application/octet-stream Size: 1445 bytes Desc: not available URL: From mdounin at mdounin.ru Tue May 14 11:41:17 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 14 May 2013 15:41:17 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: References: Message-ID: <20130514114117.GC69760@mdounin.ru> Hello! On Tue, May 14, 2013 at 02:24:31PM +0600, Илья Шипицин wrote: > Добрый день! > > предлагаю оставить только "Connection: Keep-Alive" в случае HTTP/1.0 > во всех остальных случаях предлагаю не отдавать никакой Connection. > > Аналогичным образом работает IIS. Если заголовок Keep-Alive в ответе есть, то в заголовке Connection он должен также присутствовать. Так что в таком виде патч как минимум некорректен. > еще есть вопрос, в каких условиях должен срабатывать код > > if (clcf->keepalive_header) { > len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; > } > > > в файле src/http/ngx_http_header_filter_module.c, не нашел, где > задается условие clcf->keepalive_header Указатель clcf - это ссылка на конфигурацию ngx_http_core_module, там и задётся. Значение зависит от второго параметра директивы keepalive_timeout, см. http://nginx.org/r/keepalive_timeout/ru. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue May 14 12:15:05 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 May 2013 18:15:05 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: <20130514114117.GC69760@mdounin.ru> References: <20130514114117.GC69760@mdounin.ru> Message-ID: 14 мая 2013 г., 17:41 пользователь Maxim Dounin написал: > Hello! > > On Tue, May 14, 2013 at 02:24:31PM +0600, Илья Шипицин wrote: > >> Добрый день! >> >> предлагаю оставить только "Connection: Keep-Alive" в случае HTTP/1.0 >> во всех остальных случаях предлагаю не отдавать никакой Connection. >> >> Аналогичным образом работает IIS. > > Если заголовок Keep-Alive в ответе есть, то в заголовке Connection насколько я могу судить по rfc 2616: The following HTTP/1.1 headers are hop-by-hop headers: - Connection - Keep-Alive ...... и далее HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. т.е. в ответе заголовок заголовок Keep-Alive может появиться только, если мы сами его добавим ? > он должен также присутствовать. Так что в таком виде патч > как минимум некорректен. во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся также и Connection. не вижу ничего некорректного. можете уточнить ? другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, где предполагалось. да, признаю ошибку. вложил новый патч. > >> еще есть вопрос, в каких условиях должен срабатывать код >> >> if (clcf->keepalive_header) { >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; >> } >> >> >> в файле src/http/ngx_http_header_filter_module.c, не нашел, где >> задается условие clcf->keepalive_header > > Указатель clcf - это ссылка на конфигурацию ngx_http_core_module, > там и задётся. Значение зависит от второго параметра директивы > keepalive_timeout, см. http://nginx.org/r/keepalive_timeout/ru. спасибо. не понял этот момент сразу. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- A non-text attachment was scrubbed... Name: keepalive.patch Type: application/octet-stream Size: 3126 bytes Desc: not available URL: From mdounin at mdounin.ru Tue May 14 15:16:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 14 May 2013 19:16:06 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: References: <20130514114117.GC69760@mdounin.ru> Message-ID: <20130514151605.GD69760@mdounin.ru> Hello! On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote: [...] > во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся > также и Connection. не вижу ничего некорректного. можете уточнить ? > > другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, > где предполагалось. да, признаю ошибку. вложил новый патч. Это я не досмотрел патч, и предположил не ту ошибку из двух возможных. [...] > --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013 > +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013 > @@ -382,7 +382,7 @@ > if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) { > len += sizeof("Connection: upgrade" CRLF) - 1; > > - } else if (r->keepalive) { > + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) { > len += sizeof("Connection: keep-alive" CRLF) - 1; > > /* > @@ -397,9 +397,7 @@ > len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; > } > > - } else { > - len += sizeof("Connection: close" CRLF) - 1; > - } > + } "Connection: close" при выключенном keepalive'е нужно указывать, не возвращать соответствующий заголовок - чревато ненужными проблемами и безуспешными попытками клиентов послать в то же соединение следующий запрос. Вообще я бы, честно говоря, не трогал это место. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue May 14 15:39:42 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 May 2013 21:39:42 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: <20130514151605.GD69760@mdounin.ru> References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> Message-ID: 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал: > Hello! > > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote: > > [...] > >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся >> также и Connection. не вижу ничего некорректного. можете уточнить ? >> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, >> где предполагалось. да, признаю ошибку. вложил новый патч. > > Это я не досмотрел патч, и предположил не ту ошибку из двух > возможных. > > [...] > >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013 >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013 >> @@ -382,7 +382,7 @@ >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) { >> len += sizeof("Connection: upgrade" CRLF) - 1; >> >> - } else if (r->keepalive) { >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) { >> len += sizeof("Connection: keep-alive" CRLF) - 1; >> >> /* >> @@ -397,9 +397,7 @@ >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; >> } >> >> - } else { >> - len += sizeof("Connection: close" CRLF) - 1; >> - } >> + } > > "Connection: close" при выключенном keepalive'е нужно указывать, > не возвращать соответствующий заголовок - чревато ненужными > проблемами и безуспешными попытками клиентов послать в то же > соединение следующий запрос. > я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616 8.1.4 Practical Considerations ........ A client, server, or proxy MAY close the transport connection at any time. ......... с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16% сайтов), как-то же это работает ... у нас 50 миллионов запросов в день. это в районе 1 гигабайта на хедерах "Connection:". нам эта цифра интересна. мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. > Вообще я бы, честно говоря, не трогал это место. это абстрактные опасения или вы знаете сценарии, при которых это приведет к проблемам ? > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster at softsearch.ru Tue May 14 16:05:08 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 14 May 2013 20:05:08 +0400 Subject: =?UTF-8?B?UmVbMl06INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> Message-ID: <936576392.20130514200508@softsearch.ru> Здравствуйте, Илья. > у нас 50 миллионов запросов в день. это в районе 1 гигабайта на > хедерах "Connection:". нам эта цифра интересна. > мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. Это не нужная экономия. Актуально может было бы ещё тем, кто браузером ходит через узкий канал, но уж точно не тем, кто раздаёт контент. -- С уважением, Михаил mailto:postmaster at softsearch.ru From chipitsine at gmail.com Tue May 14 16:09:37 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 May 2013 22:09:37 +0600 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9Cw0YLRhyDQtNC70Y8gQ29ubmVjdGlvbjogS2VlcC1BbGl2?= =?UTF-8?B?ZQ==?= In-Reply-To: <936576392.20130514200508@softsearch.ru> References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> <936576392.20130514200508@softsearch.ru> Message-ID: ну так, чтобы пользователю на узком канале прилетело меньше трафика, надо меньше его отдать. 14 мая 2013 г., 22:05 пользователь Михаил Монашёв написал: > Здравствуйте, Илья. > >> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на >> хедерах "Connection:". нам эта цифра интересна. >> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. > > Это не нужная экономия. Актуально может было бы ещё тем, кто браузером > ходит через узкий канал, но уж точно не тем, кто раздаёт контент. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue May 14 16:17:27 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 14 May 2013 20:17:27 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> Message-ID: <20130514161727.GE69760@mdounin.ru> Hello! On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote: > 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал: > > Hello! > > > > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote: > > > > [...] > > > >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся > >> также и Connection. не вижу ничего некорректного. можете уточнить ? > >> > >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, > >> где предполагалось. да, признаю ошибку. вложил новый патч. > > > > Это я не досмотрел патч, и предположил не ту ошибку из двух > > возможных. > > > > [...] > > > >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013 > >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013 > >> @@ -382,7 +382,7 @@ > >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) { > >> len += sizeof("Connection: upgrade" CRLF) - 1; > >> > >> - } else if (r->keepalive) { > >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) { > >> len += sizeof("Connection: keep-alive" CRLF) - 1; > >> > >> /* > >> @@ -397,9 +397,7 @@ > >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; > >> } > >> > >> - } else { > >> - len += sizeof("Connection: close" CRLF) - 1; > >> - } > >> + } > > > > "Connection: close" при выключенном keepalive'е нужно указывать, > > не возвращать соответствующий заголовок - чревато ненужными > > проблемами и безуспешными попытками клиентов послать в то же > > соединение следующий запрос. > > > > я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616 > > 8.1.4 Practical Considerations > > > ........ > > A client, server, or proxy MAY close the transport connection at any > time. > ......... > > > Это _можно_ делать, но на практике - это приводит к сильно неоптимальному поведению клиентов. Поэтому убирать "Connection: close" из ответов, keepalive в которых не предполагается - это плохая идея. С учётом того, что keepalive в нормальных условиях влючён чуть более, чем всегда - убирать "Connection: close" не представляется разумным ни с какой точки зрения. > с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16% > сайтов), как-то же это работает ... Специально сходил проверил на первый попавшийся сайт с IIS'ом - _так_ IIS, насколько я вижу, не поступает: $ telnet W3schools.com 80 Trying 66.29.212.73... Connected to W3schools.com. Escape character is '^]'. HEAD / HTTP/1.1 Host: w3scools.com HTTP/1.1 200 OK Cache-Control: private Content-Length: 29839 Content-Type: text/html Server: Microsoft-IIS/7.5 Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/ X-Powered-By: ASP.NET Date: Tue, 14 May 2013 16:10:08 GMT HEAD / HTTP/1.1 Host: w3scools.com Connection: close HTTP/1.1 200 OK Cache-Control: private Content-Length: 29839 Content-Type: text/html Server: Microsoft-IIS/7.5 Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/ X-Powered-By: ASP.NET Date: Tue, 14 May 2013 16:10:28 GMT Connection: close Connection closed by foreign host. Т.е. если соединение закрывается - то "Connection: close" в ответе присутствует. > у нас 50 миллионов запросов в день. это в районе 1 гигабайта на > хедерах "Connection:". нам эта цифра интересна. > мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. > > > > Вообще я бы, честно говоря, не трогал это место. > > это абстрактные опасения или вы знаете сценарии, при которых это > приведет к проблемам ? При правильной реализации - т.е. не слать "Connection: keep-alive" для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся - только абстрактные. Все изложенные выше замечания - вполне конкретные. Just in case, правильный патч какой-то такой: --- a/src/http/ngx_http_header_filter_module.c +++ b/src/http/ngx_http_header_filter_module.c @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_ len += sizeof("Connection: upgrade" CRLF) - 1; } else if (r->keepalive) { - len += sizeof("Connection: keep-alive" CRLF) - 1; + + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { + len += sizeof("Connection: keep-alive" CRLF) - 1; + } /* * MSIE and Opera ignore the "Keep-Alive: timeout=" header. @@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_ sizeof("Connection: upgrade" CRLF) - 1); } else if (r->keepalive) { - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, - sizeof("Connection: keep-alive" CRLF) - 1); + + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, + sizeof("Connection: keep-alive" CRLF) - 1); + } if (clcf->keepalive_header) { b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Tue May 14 16:24:31 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 14 May 2013 22:24:31 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: <20130514161727.GE69760@mdounin.ru> References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> <20130514161727.GE69760@mdounin.ru> Message-ID: не слать "Connection: Keep-Alive" для HTTP/1.1 - статистически то же самое, что я предлагал (ввиду малораспространенности не-кипэлайв-соединений) давайте так и сделаем ? вариант "не слать Connection никогда" мы на кошках проверим, потом расскажу. 14 мая 2013 г., 22:17 пользователь Maxim Dounin написал: > Hello! > > On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote: > >> 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал: >> > Hello! >> > >> > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote: >> > >> > [...] >> > >> >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся >> >> также и Connection. не вижу ничего некорректного. можете уточнить ? >> >> >> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, >> >> где предполагалось. да, признаю ошибку. вложил новый патч. >> > >> > Это я не досмотрел патч, и предположил не ту ошибку из двух >> > возможных. >> > >> > [...] >> > >> >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013 >> >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013 >> >> @@ -382,7 +382,7 @@ >> >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) { >> >> len += sizeof("Connection: upgrade" CRLF) - 1; >> >> >> >> - } else if (r->keepalive) { >> >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) { >> >> len += sizeof("Connection: keep-alive" CRLF) - 1; >> >> >> >> /* >> >> @@ -397,9 +397,7 @@ >> >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; >> >> } >> >> >> >> - } else { >> >> - len += sizeof("Connection: close" CRLF) - 1; >> >> - } >> >> + } >> > >> > "Connection: close" при выключенном keepalive'е нужно указывать, >> > не возвращать соответствующий заголовок - чревато ненужными >> > проблемами и безуспешными попытками клиентов послать в то же >> > соединение следующий запрос. >> > >> >> я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616 >> >> 8.1.4 Practical Considerations >> >> >> ........ >> >> A client, server, or proxy MAY close the transport connection at any >> time. >> ......... >> >> >> > > Это _можно_ делать, но на практике - это приводит к сильно > неоптимальному поведению клиентов. Поэтому убирать "Connection: > close" из ответов, keepalive в которых не предполагается - это > плохая идея. > > С учётом того, что keepalive в нормальных условиях влючён чуть > более, чем всегда - убирать "Connection: close" не представляется > разумным ни с какой точки зрения. > >> с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16% >> сайтов), как-то же это работает ... > > Специально сходил проверил на первый попавшийся сайт с IIS'ом - > _так_ IIS, насколько я вижу, не поступает: > > $ telnet W3schools.com 80 > Trying 66.29.212.73... > Connected to W3schools.com. > Escape character is '^]'. > HEAD / HTTP/1.1 > Host: w3scools.com > > HTTP/1.1 200 OK > Cache-Control: private > Content-Length: 29839 > Content-Type: text/html > Server: Microsoft-IIS/7.5 > Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/ > X-Powered-By: ASP.NET > Date: Tue, 14 May 2013 16:10:08 GMT > > HEAD / HTTP/1.1 > Host: w3scools.com > Connection: close > > HTTP/1.1 200 OK > Cache-Control: private > Content-Length: 29839 > Content-Type: text/html > Server: Microsoft-IIS/7.5 > Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/ > X-Powered-By: ASP.NET > Date: Tue, 14 May 2013 16:10:28 GMT > Connection: close > > Connection closed by foreign host. > > Т.е. если соединение закрывается - то "Connection: close" в ответе > присутствует. > >> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на >> хедерах "Connection:". нам эта цифра интересна. >> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. >> >> >> > Вообще я бы, честно говоря, не трогал это место. >> >> это абстрактные опасения или вы знаете сценарии, при которых это >> приведет к проблемам ? > > При правильной реализации - т.е. не слать "Connection: keep-alive" > для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся - > только абстрактные. Все изложенные выше замечания - вполне > конкретные. > > Just in case, правильный патч какой-то такой: > > --- a/src/http/ngx_http_header_filter_module.c > +++ b/src/http/ngx_http_header_filter_module.c > @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_ > len += sizeof("Connection: upgrade" CRLF) - 1; > > } else if (r->keepalive) { > - len += sizeof("Connection: keep-alive" CRLF) - 1; > + > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > + len += sizeof("Connection: keep-alive" CRLF) - 1; > + } > > /* > * MSIE and Opera ignore the "Keep-Alive: timeout=" header. > @@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_ > sizeof("Connection: upgrade" CRLF) - 1); > > } else if (r->keepalive) { > - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > - sizeof("Connection: keep-alive" CRLF) - 1); > + > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > + sizeof("Connection: keep-alive" CRLF) - 1); > + } > > if (clcf->keepalive_header) { > b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, > > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue May 14 16:37:58 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 14 May 2013 20:37:58 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyBDb25uZWN0aW9uOiBLZWVwLUFsaXZl?= In-Reply-To: References: <20130514114117.GC69760@mdounin.ru> <20130514151605.GD69760@mdounin.ru> <20130514161727.GE69760@mdounin.ru> Message-ID: <20130514163758.GF69760@mdounin.ru> Hello! On Tue, May 14, 2013 at 10:24:31PM +0600, Илья Шипицин wrote: > не слать "Connection: Keep-Alive" для HTTP/1.1 - статистически то же > самое, что я предлагал (ввиду малораспространенности > не-кипэлайв-соединений) > > давайте так и сделаем ? Я очень не хочу это трогать, по крайней мере - без тщательного тестирования. > вариант "не слать Connection никогда" мы на кошках проверим, потом расскажу. В рассылках периодически жалуются даже на те очень нечастые ситуцаии, когда nginx так всё-таки делает (e.g., при переконфигурации). > > 14 мая 2013 г., 22:17 пользователь Maxim Dounin написал: > > Hello! > > > > On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote: > > > >> 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал: > >> > Hello! > >> > > >> > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote: > >> > > >> > [...] > >> > > >> >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся > >> >> также и Connection. не вижу ничего некорректного. можете уточнить ? > >> >> > >> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там, > >> >> где предполагалось. да, признаю ошибку. вложил новый патч. > >> > > >> > Это я не досмотрел патч, и предположил не ту ошибку из двух > >> > возможных. > >> > > >> > [...] > >> > > >> >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013 > >> >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013 > >> >> @@ -382,7 +382,7 @@ > >> >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) { > >> >> len += sizeof("Connection: upgrade" CRLF) - 1; > >> >> > >> >> - } else if (r->keepalive) { > >> >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) { > >> >> len += sizeof("Connection: keep-alive" CRLF) - 1; > >> >> > >> >> /* > >> >> @@ -397,9 +397,7 @@ > >> >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2; > >> >> } > >> >> > >> >> - } else { > >> >> - len += sizeof("Connection: close" CRLF) - 1; > >> >> - } > >> >> + } > >> > > >> > "Connection: close" при выключенном keepalive'е нужно указывать, > >> > не возвращать соответствующий заголовок - чревато ненужными > >> > проблемами и безуспешными попытками клиентов послать в то же > >> > соединение следующий запрос. > >> > > >> > >> я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616 > >> > >> 8.1.4 Practical Considerations > >> > >> > >> ........ > >> > >> A client, server, or proxy MAY close the transport connection at any > >> time. > >> ......... > >> > >> > >> > > > > Это _можно_ делать, но на практике - это приводит к сильно > > неоптимальному поведению клиентов. Поэтому убирать "Connection: > > close" из ответов, keepalive в которых не предполагается - это > > плохая идея. > > > > С учётом того, что keepalive в нормальных условиях влючён чуть > > более, чем всегда - убирать "Connection: close" не представляется > > разумным ни с какой точки зрения. > > > >> с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16% > >> сайтов), как-то же это работает ... > > > > Специально сходил проверил на первый попавшийся сайт с IIS'ом - > > _так_ IIS, насколько я вижу, не поступает: > > > > $ telnet W3schools.com 80 > > Trying 66.29.212.73... > > Connected to W3schools.com. > > Escape character is '^]'. > > HEAD / HTTP/1.1 > > Host: w3scools.com > > > > HTTP/1.1 200 OK > > Cache-Control: private > > Content-Length: 29839 > > Content-Type: text/html > > Server: Microsoft-IIS/7.5 > > Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/ > > X-Powered-By: ASP.NET > > Date: Tue, 14 May 2013 16:10:08 GMT > > > > HEAD / HTTP/1.1 > > Host: w3scools.com > > Connection: close > > > > HTTP/1.1 200 OK > > Cache-Control: private > > Content-Length: 29839 > > Content-Type: text/html > > Server: Microsoft-IIS/7.5 > > Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/ > > X-Powered-By: ASP.NET > > Date: Tue, 14 May 2013 16:10:28 GMT > > Connection: close > > > > Connection closed by foreign host. > > > > Т.е. если соединение закрывается - то "Connection: close" в ответе > > присутствует. > > > >> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на > >> хедерах "Connection:". нам эта цифра интересна. > >> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. > >> > >> > >> > Вообще я бы, честно говоря, не трогал это место. > >> > >> это абстрактные опасения или вы знаете сценарии, при которых это > >> приведет к проблемам ? > > > > При правильной реализации - т.е. не слать "Connection: keep-alive" > > для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся - > > только абстрактные. Все изложенные выше замечания - вполне > > конкретные. > > > > Just in case, правильный патч какой-то такой: > > > > --- a/src/http/ngx_http_header_filter_module.c > > +++ b/src/http/ngx_http_header_filter_module.c > > @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_ > > len += sizeof("Connection: upgrade" CRLF) - 1; > > > > } else if (r->keepalive) { > > - len += sizeof("Connection: keep-alive" CRLF) - 1; > > + > > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > > + len += sizeof("Connection: keep-alive" CRLF) - 1; > > + } > > > > /* > > * MSIE and Opera ignore the "Keep-Alive: timeout=" header. > > @@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_ > > sizeof("Connection: upgrade" CRLF) - 1); > > > > } else if (r->keepalive) { > > - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > > - sizeof("Connection: keep-alive" CRLF) - 1); > > + > > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > > + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > > + sizeof("Connection: keep-alive" CRLF) - 1); > > + } > > > > if (clcf->keepalive_header) { > > b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, > > > > > > -- > > Maxim Dounin > > http://nginx.org/en/donation.html > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue May 14 16:44:18 2013 From: nginx-forum at nginx.us (Blangel) Date: Tue, 14 May 2013 12:44:18 -0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9Cw0YLRhyDQtNC70Y8gQ29ubmVjdGlvbjogS2VlcC1BbGl2?= =?UTF-8?B?ZQ==?= In-Reply-To: <936576392.20130514200508@softsearch.ru> References: <936576392.20130514200508@softsearch.ru> Message-ID: Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Илья. > > > у нас 50 миллионов запросов в день. это в районе 1 гигабайта на > > хедерах "Connection:". нам эта цифра интересна. > > мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту. > > Это не нужная экономия. Актуально может было бы ещё тем, кто браузером > ходит через узкий канал, но уж точно не тем, кто раздаёт контент. Узкий канал => Transfer-Encoding: chunked => отсутствует Content-Length => => Какая разница, есть заголовок Connection или нет? Клиент все равно не знает, когда закончится ответ сервера, пока сервер не закончит. В случае с Keep-Alive это не сломается, потому что Google не отдает Keep-Alive, и вроде бы забаненных в Гугле мы не наблюдаем.... В случае с Close тоже не сломается, потому что клиент все равно не знает, когда закрыть соединение - т.е. решает сервер. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239165,239190#msg-239190 From nginx-forum at nginx.us Wed May 15 05:55:27 2013 From: nginx-forum at nginx.us (r3l0c) Date: Wed, 15 May 2013 01:55:27 -0400 Subject: =?UTF-8?B?UmU6INCa0YDRj9C60L7Qt9GP0LHRiyDQsiDQutC10YjQuNGA0L7QstCw0L3QvdGL?= =?UTF-8?B?0YUg0YTQsNC50LvQsNGFIHByb3h5IHN0b3Jl?= In-Reply-To: <20130513071507.GY69760@mdounin.ru> References: <20130513071507.GY69760@mdounin.ru> Message-ID: Решил проблему, был включен gzip, но хз почему такой косяк был Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239110,239209#msg-239209 From nginx-forum at nginx.us Wed May 15 09:46:22 2013 From: nginx-forum at nginx.us (itonohito) Date: Wed, 15 May 2013 05:46:22 -0400 Subject: =?UTF-8?B?0JTQvtGB0YLRg9C/INC/0L4gaXAg0JjQm9CYINGH0LXRgNC10Lcg0LrQu9C40LU=?= =?UTF-8?B?0L3RgtGB0LrQuNC5INGB0LXRgNGC0LjRhNC40LrQsNGCIC0g0LLQvtC30Lw=?= =?UTF-8?B?0L7QttC90L4g0LvQuD8=?= Message-ID: <98c0c860860cded8dc34304528e3f27a.NginxMailingListRussian@forum.nginx.org> Добрый день! Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip? Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с любого ip, а кроме того - с некоторых ip доступ был для всех и без сертификата тоже. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239218,239218#msg-239218 From pavel2000 at ngs.ru Wed May 15 10:57:54 2013 From: pavel2000 at ngs.ru (Pavel V.) Date: Wed, 15 May 2013 17:57:54 +0700 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IGlwINCY0JvQmCDRh9C10YDQtdC3INC60Ls=?= =?UTF-8?B?0LjQtdC90YLRgdC60LjQuSDRgdC10YDRgtC40YTQuNC60LDRgiAtINCy0L4=?= =?UTF-8?B?0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: <98c0c860860cded8dc34304528e3f27a.NginxMailingListRussian@forum.nginx.org> References: <98c0c860860cded8dc34304528e3f27a.NginxMailingListRussian@forum.nginx.org> Message-ID: <981738352.20130515175754@ngs.ru> Здравствуйте, itonohito. Вы писали 15 мая 2013 г., 16:46:22: > Добрый день! > Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к > сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip? > Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с > любого ip, а кроме того - с некоторых ip доступ был для всех и без > сертификата тоже. Здравствуйте. Вы можете сконфигурировать отдельный server {} на отдельном порту, разрешающий доступ по IP без требования сертификата, и завернуть трафик с "некоторых IP" на этот порт, например через iptables -t nat -I PREROUTING -s 1.2.3.4/25 -d 8.8.7.7 -p tcp --dport 443 -j DNAT --to-destination=8.8.7.7:444 -- С уважением, Pavel mailto:pavel2000 at ngs.ru From chipitsine at gmail.com Wed May 15 12:52:37 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 15 May 2013 18:52:37 +0600 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+IGlwINCY0JvQmCDRh9C10YDQtdC3INC60Ls=?= =?UTF-8?B?0LjQtdC90YLRgdC60LjQuSDRgdC10YDRgtC40YTQuNC60LDRgiAtINCy0L4=?= =?UTF-8?B?0LfQvNC+0LbQvdC+INC70Lg/?= In-Reply-To: <98c0c860860cded8dc34304528e3f27a.NginxMailingListRussian@forum.nginx.org> References: <98c0c860860cded8dc34304528e3f27a.NginxMailingListRussian@forum.nginx.org> Message-ID: если требовать сертификат, то в случае, если сертификат не предъявлен, nginx генерирует внутреннюю ошибку 495. делаете "error_page 495 = @fallback;", все, кто пришел без сертификата, отправляются в @fallback, там пробиваете по IP. как-то так. 15 мая 2013 г., 15:46 пользователь itonohito написал: > Добрый день! > > Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к > сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip? > Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с > любого ip, а кроме того - с некоторых ip доступ был для всех и без > сертификата тоже. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239218,239218#msg-239218 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu May 16 09:35:10 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 16 May 2013 05:35:10 -0400 Subject: nginx location single php file Message-ID: <4ad0e427601fc47388532a9851c3c5f8.NginxMailingListRussian@forum.nginx.org> Всем привет. Нужно отключить basic авторизацию для запроса http://domain.com/rpc.php?jkfgsdkfg. Для всего сайта включена basic авторизация. Создаю новый location : location ~ /rpc.php { auth_basic off; fastcgi_pass 127.0.0.1:9000; fastcgi_param DOCUMENT_ROOT /www; fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE "CGI/1.1"; fastcgi_param SERVER_NAME $server_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param REMOTE_USER $remote_user; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code; fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name; fastcgi_param GEOIP_REGION $geoip_region; fastcgi_param GEOIP_CITY $geoip_city; } Но не работает (то есть, всё равно требуется авторизация). Хотя вот такие location'ы вполне работают (то есть, при запросе http://domain.com/ajax/jfsgf.php?fhfsl - basic авторизация не запрашивается): location /ajax { auth_basic off; alias /www/ajax; } location ~ /ajax/(.*\.php)$ { auth_basic off; fastcgi_pass 127.0.0.1:9000; fastcgi_param DOCUMENT_ROOT /www; fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE "CGI/1.1"; fastcgi_param SERVER_NAME $server_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param REMOTE_USER $remote_user; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code; fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name; fastcgi_param GEOIP_REGION $geoip_region; fastcgi_param GEOIP_CITY $geoip_city; } Не могу понять, почему запрашивается basic авторизация при запросе http://domain.com/rpc.php и как её отключить. Уже по разному пробовал location менять: location = /rpc.php location /rpc.php не работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239256,239256#msg-239256 From andrey at kopeyko.ru Thu May 16 09:52:27 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Thu, 16 May 2013 13:52:27 +0400 Subject: nginx location single php file In-Reply-To: <4ad0e427601fc47388532a9851c3c5f8.NginxMailingListRussian@forum.nginx.org> References: <4ad0e427601fc47388532a9851c3c5f8.NginxMailingListRussian@forum.nginx.org> Message-ID: <5194AC5B.3090202@kopeyko.ru> 16.05.2013 13:35, skeletor пишет: > Всем привет. Добрый день! > Нужно отключить basic авторизацию для запроса ... > Не могу понять, почему запрашивается basic авторизация при запросе > http://domain.com/rpc.php и как её отключить. А вы включите debug log и почитайте как же на самом деле ваш запрос обрабатывается. -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Thu May 16 10:19:33 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 16 May 2013 06:19:33 -0400 Subject: nginx location single php file In-Reply-To: <5194AC5B.3090202@kopeyko.ru> References: <5194AC5B.3090202@kopeyko.ru> Message-ID: <67ec747eddcbd280cee98cf7f46dbb15.NginxMailingListRussian@forum.nginx.org> Спасибо за наводку, но вижу только обработку server_name (там у меня regexp). Nginx собран без модуля echo, а без него протестировать location'ы невозможно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239256,239258#msg-239258 From mdounin at mdounin.ru Thu May 16 11:11:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 16 May 2013 15:11:07 +0400 Subject: nginx location single php file In-Reply-To: <67ec747eddcbd280cee98cf7f46dbb15.NginxMailingListRussian@forum.nginx.org> References: <5194AC5B.3090202@kopeyko.ru> <67ec747eddcbd280cee98cf7f46dbb15.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130516111107.GN69760@mdounin.ru> Hello! On Thu, May 16, 2013 at 06:19:33AM -0400, skeletor wrote: > Спасибо за наводку, но вижу только обработку server_name (там у меня > regexp). Видимо, nginx собран без debug'а. Подробнее тут: http://nginx.org/ru/docs/debugging_log.html > Nginx собран без модуля echo, а без него протестировать location'ы > невозможно. Способов масса, начиная от "return 418;" (или более гуманного return 200 OK;") в проверяемом месте. Хотя проще всего - с debug log'ом, как Андрей уже порекомендовал. Впрочем, заявленное "не работает location = /rpc.php" говорит о том, что выбор location'а - не при чём, и проблема в чём-то другом. E.g., если вы тестируете браузером, - авторизация может запрышиваться не для самой страницы, а для дополнительных ресурсов - картинок и т.п. - которые грузятся с других адресов. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-ru at sadok.spb.ru Thu May 16 11:11:57 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Thu, 16 May 2013 15:11:57 +0400 Subject: nginx location single php file In-Reply-To: <4ad0e427601fc47388532a9851c3c5f8.NginxMailingListRussian@forum.nginx.org> References: <4ad0e427601fc47388532a9851c3c5f8.NginxMailingListRussian@forum.nginx.org> Message-ID: <1931049948.20130516151157@sadok.spb.ru> Здравствуйте, skeletor. Вы писали 16 мая 2013 г., 13:35:10: > Всем привет. > Нужно отключить basic авторизацию для запроса > http://domain.com/rpc.php?jkfgsdkfg. Для всего сайта включена basic > авторизация. Создаю новый location : Наверняка подсасывается чот-то, не лежащее в /rpc.php (картинки, css etc) Посмотрите тем же Хромом (Инструменты разработчка - Network), что на самом деле запрашивается. Сам вчера наступил на такое. -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Thu May 16 11:12:57 2013 From: nginx-forum at nginx.us (AMax) Date: Thu, 16 May 2013 07:12:57 -0400 Subject: =?UTF-8?Q?location_=D0=B8_proxy_pass?= Message-ID: <01a713f8a7784652d890f1d46acee2ab.NginxMailingListRussian@forum.nginx.org> Есть такой server: server { listen 80; server_name example.com www.example.com; access_log /var/log/nginx/example.com/access.log main; error_log /var/log/nginx/example.com/error.log; include /etc/nginx/cloudflare_params; location /w/images/ { root /var/www/data/example.com; # log only hotlinking if ($http_referer ~* "^http://(www\.)?example\.com/.*$" ) { access_log off; } } location /w/skins/ { root /var/www/data/example.com; access_log off; } location ~ ^/w/extensions/.*?\.(sql|php)$ { return 403; } # location ^~ /w/load.php { # proxy_pass http://127.0.0.1:81/; # include /etc/nginx/proxy_params; # access_log off; # } location / { proxy_pass http://127.0.0.1:81/; include /etc/nginx/proxy_params; } } Если раскомментировать location ^~ /w/load.php, он перестает работать, точнее возвращает некорректный ответ от сервера, хотя, вроде бы, должен обрабатываться тем же backend с теми же параметрами, только не писать в журнал. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239260,239260#msg-239260 From nginx-forum at nginx.us Thu May 16 11:45:36 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 16 May 2013 07:45:36 -0400 Subject: nginx location single php file In-Reply-To: <1931049948.20130516151157@sadok.spb.ru> References: <1931049948.20130516151157@sadok.spb.ru> Message-ID: <1bbe598d77d29ddfe241de90a4e23c75.NginxMailingListRussian@forum.nginx.org> Проверяю curl'ом. Для теста поместил в файл rpc.php текст . Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239256,239266#msg-239266 From nginx-forum at nginx.us Thu May 16 12:22:59 2013 From: nginx-forum at nginx.us (skeletor) Date: Thu, 16 May 2013 08:22:59 -0400 Subject: nginx location single php file In-Reply-To: <1931049948.20130516151157@sadok.spb.ru> References: <1931049948.20130516151157@sadok.spb.ru> Message-ID: <04eb8872ceb18f677b652c8c55cfc6ab.NginxMailingListRussian@forum.nginx.org> Спасибо всем за помощь. Проблема была на поверхности, а именно - не слушался порт 9000. То есть банально php-fpm не работал. Вот, правильный (работает и тот, но этот точнее будет; как видно отличие только в = и ~) location = /rpc.php { auth_basic off; fastcgi_pass 127.0.0.1:9000; fastcgi_param DOCUMENT_ROOT /www; fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE "CGI/1.1"; fastcgi_param SERVER_NAME $server_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param REMOTE_USER $remote_user; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code; fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name; fastcgi_param GEOIP_REGION $geoip_region; fastcgi_param GEOIP_CITY $geoip_city; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239256,239269#msg-239269 From mdounin at mdounin.ru Thu May 16 13:10:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 16 May 2013 17:10:20 +0400 Subject: =?UTF-8?Q?Re=3A_location_=D0=B8_proxy_pass?= In-Reply-To: <01a713f8a7784652d890f1d46acee2ab.NginxMailingListRussian@forum.nginx.org> References: <01a713f8a7784652d890f1d46acee2ab.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130516131019.GQ69760@mdounin.ru> Hello! On Thu, May 16, 2013 at 07:12:57AM -0400, AMax wrote: > Есть такой server: > > server { > listen 80; > server_name example.com www.example.com; > > access_log /var/log/nginx/example.com/access.log main; > error_log /var/log/nginx/example.com/error.log; > include /etc/nginx/cloudflare_params; > > location /w/images/ { > root /var/www/data/example.com; > # log only hotlinking > if ($http_referer ~* "^http://(www\.)?example\.com/.*$" ) { > access_log off; > } > } > > location /w/skins/ { > root /var/www/data/example.com; > access_log off; > } > > location ~ ^/w/extensions/.*?\.(sql|php)$ { return 403; } > > # location ^~ /w/load.php { > # proxy_pass http://127.0.0.1:81/; > # include /etc/nginx/proxy_params; > # access_log off; > # } > > location / { > proxy_pass http://127.0.0.1:81/; > include /etc/nginx/proxy_params; > } > } > > Если раскомментировать location ^~ /w/load.php, он перестает работать, > точнее возвращает некорректный ответ от сервера, хотя, вроде бы, должен > обрабатываться тем же backend с теми же параметрами, только не писать в > журнал. Поскольку используется proxy_pass с URI - указанный URI заменяет совпавшую с location'ом часть URI запроса. Для location / - замена "/" на "/" ни на что не влияет, а вот для location /w/load.php - замена "/w/load.php" на "/" логично приводит к тому, что оно перестаёт работать. Проще всего убрать "/" в конце proxy_pass: location = /w/load.php { proxy_pass http://127.0.0.1:81; ... } Подробнее см. http://nginx.org/r/proxy_pass/ru. -- Maxim Dounin http://nginx.org/en/donation.html From andrey at kopeyko.ru Thu May 16 17:15:44 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Thu, 16 May 2013 21:15:44 +0400 Subject: nginx location single php file In-Reply-To: <04eb8872ceb18f677b652c8c55cfc6ab.NginxMailingListRussian@forum.nginx.org> References: <1931049948.20130516151157@sadok.spb.ru> <04eb8872ceb18f677b652c8c55cfc6ab.NginxMailingListRussian@forum.nginx.org> Message-ID: <51951440.8090208@kopeyko.ru> 16.05.2013 16:22, skeletor пишет: > Спасибо всем за помощь. > Проблема была на поверхности, а именно - не слушался порт 9000. Вы какую-то пургу несёте - если бы дело было именно в этом, вы бы получали "502". Вы же получали "401", а это значит что Максим прав - ваш запрос обрабатывался в каком-то другом локейшене. Включите уж debug log да и посмотрите. То, что у вас всё теперь заработало - говорит не о том, что вы разобрались и искоренили проблему, а, скорее, о случайности - какое-то другое ваше изменение, в той части конфига что вы не показали, привело к тому что обработка запроса стала попадать в этот локейшн. Следующее ваше изменение конфига - запросто может развалить всё вновь, готовьтесь. -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Fri May 17 04:55:28 2013 From: nginx-forum at nginx.us (bespechnost) Date: Fri, 17 May 2013 00:55:28 -0400 Subject: =?UTF-8?B?cHJveHkgcGFzcyDRh9C10YDQtdC3INC/0LXRgNC10LzQtdC90L3Rg9GOINC90LUg?= =?UTF-8?B?0YDQsNCx0L7RgtCw0LXRgg==?= Message-ID: Пробую так: location /omlet_api/ { proxy_pass http://$arg_server/; proxy_set_header Host $arg_server; break; } В логах: ==> localhost.error_log <== 2013/05/17 08:48:59 [error] 16907#0: *1 no resolver defined to resolve ya.ru, client: 127.0.0.1, server: localhost, request: "GET /omlet_api/genres/?server=ya.ru HTTP/1.1", host: "localhost" Если заменить $arg_server на имя сервера, то все работает. Версия NGINX - 1.2.6-r1 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239286,239286#msg-239286 From vadim.lazovskiy at gmail.com Fri May 17 05:45:05 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 17 May 2013 09:45:05 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0YfQtdGA0LXQtyDQv9C10YDQtdC80LXQvdC90YPRjiA=?= =?UTF-8?B?0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= In-Reply-To: References: Message-ID: Здравствуйте. Задайте http://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver в конфиге. 2013/5/17 bespechnost > Пробую так: > location /omlet_api/ { > proxy_pass http://$arg_server/; > proxy_set_header Host $arg_server; > break; > } > > В логах: > ==> localhost.error_log <== > 2013/05/17 08:48:59 [error] 16907#0: *1 no resolver defined to resolve > ya.ru, client: 127.0.0.1, server: localhost, request: "GET > /omlet_api/genres/?server=ya.ru HTTP/1.1", host: "localhost" > > Если заменить $arg_server на имя сервера, то все работает. > > Версия NGINX - 1.2.6-r1 > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239286,239286#msg-239286 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri May 17 10:35:03 2013 From: nginx-forum at nginx.us (ast) Date: Fri, 17 May 2013 06:35:03 -0400 Subject: Amazon ELB = Nginx ? Message-ID: <25616eea2a1cdea26106b4b47d1172b7.NginxMailingListRussian@forum.nginx.org> Всем привет. Из чистого любопытства:) http://www.e-xecutive.ru/startup/story/1823978/ Есть такое интервью. В нем есть вот эта фраза: "На третье направление сейчас делаем основную ставку ? это коммерческий продукт на базе Nginx, над которым мы два года работаем. Фактически это тот же Nginx с открытым кодом плюс компоненты с закрытым кодом. Продукт уже доступен в облаке Amazon" Была не очень подтвержденная инфа, что амазоновский ELB использует модифицированный Nginx. Насколько я понимаю, то теперь это подтверждается точно? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239289,239289#msg-239289 From defan at nginx.com Fri May 17 10:50:29 2013 From: defan at nginx.com (Andrei Belov) Date: Fri, 17 May 2013 14:50:29 +0400 Subject: Amazon ELB = Nginx ? In-Reply-To: <25616eea2a1cdea26106b4b47d1172b7.NginxMailingListRussian@forum.nginx.org> References: <25616eea2a1cdea26106b4b47d1172b7.NginxMailingListRussian@forum.nginx.org> Message-ID: <629A271A-33DC-4B69-AFE2-0B0CC32AD3F2@nginx.com> On May 17, 2013, at 14:35 , ast wrote: > Всем привет. Из чистого любопытства:) > > http://www.e-xecutive.ru/startup/story/1823978/ > > Есть такое интервью. В нем есть вот эта фраза: > > "На третье направление сейчас делаем основную ставку ? это коммерческий > продукт на базе Nginx, над которым мы два года работаем. Фактически это тот > же Nginx с открытым кодом плюс компоненты с закрытым кодом. Продукт уже > доступен в облаке Amazon" > > Была не очень подтвержденная инфа, что амазоновский ELB использует > модифицированный Nginx. Насколько я понимаю, то теперь это подтверждается > точно? Нет, ELB тут ни при чём. From universite at ukr.net Fri May 17 16:10:55 2013 From: universite at ukr.net (Vladislav Prodan) Date: Fri, 17 May 2013 19:10:55 +0300 Subject: =?UTF-8?B?0JrQsNC6INC+0YLQtNCw0LLQsNGC0Ywg0LTQu9GPIGRlbnkgSVA7INCy0LzQtdGB?= =?UTF-8?B?0YLQviA0MDMgLSA1MDM/?= Message-ID: <88206.1368807055.9310451219386990592@ffe15.ukr.net> Сабж. Список IP глобальный, определен выше секций server. Поэтому такая схема не помогает: error_page 403 = @403; location @403 { keepalive_timeout 0; return 503; } -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From nginx-forum at nginx.us Sat May 18 09:17:00 2013 From: nginx-forum at nginx.us (megalodon) Date: Sat, 18 May 2013 05:17:00 -0400 Subject: =?UTF-8?B?0KPQstC10LTQvtC80LvQtdC90LjQtSDQvNC+0LTRg9C70Y8g0L4g0YLQvtC8LCA=?= =?UTF-8?B?0YfRgtC+INGB0LXRgdGB0LjRjyDQt9Cw0LLQtdGA0YjQuNC70LDRgdGM?= Message-ID: <0d59a7bc7aec51333eb6e90776945cce.NginxMailingListRussian@forum.nginx.org> Всем доброго дня. Пишу модуль под nginx. Управление передается модулю, когда прилетает request и наступает соответсвующая фаза обработки. Но, что если запрос не прилетел, а сессия закрылась по тайм-ауту со стороны nginx либо от клиента явно прилетел FIN или RST? Как при наступлении такого события можно передать упраление в модуль? Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239313,239313#msg-239313 From kav at karagodov.name Sun May 19 07:36:40 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Sun, 19 May 2013 11:36:40 +0400 Subject: =?UTF-8?B?UmU6IFtTUEFNXdCa0LDQuiDQvtGC0LTQsNCy0LDRgtGMINC00LvRjyBkZW55IElQ?= =?UTF-8?B?OyDQstC80LXRgdGC0L4gNDAzIC0gNTAzPw==?= In-Reply-To: <88206.1368807055.9310451219386990592@ffe15.ukr.net> References: <88206.1368807055.9310451219386990592@ffe15.ukr.net> Message-ID: On 17.05.2013, at 20:10, Vladislav Prodan wrote: > > Сабж. > > Список IP глобальный, определен выше секций server. как временная мера - список и пр части конфига можно заинклудить в любом месте > > Поэтому такая схема не помогает: > > error_page 403 = @403; > > location @403 { > keepalive_timeout 0; > return 503; > } > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Mon May 20 04:31:10 2013 From: nginx-forum at nginx.us (kasak) Date: Mon, 20 May 2013 00:31:10 -0400 Subject: =?UTF-8?Q?400_Bad_Request_=D0=B2_Mercurial?= Message-ID: <7c004a7660960d0c9b08acdedfce2146.NginxMailingListRussian@forum.nginx.org> Имеется репозиторий на меркуриале, работает через Apache на внутреннем сервере, nginx стоит на шлюзе и проксирует запросы на внутренний сервер. С определённого момента стало невозможным через nginx сделать pull, хотя clone работает. При попытке сделать pull получаем 400:bad request. В error.log ничего, вот конфиг: server { listen 80; server_name hg.somesite.ru; large_client_header_buffers 4 128k; location / { proxy_pass http://al-dabaran; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Proxy-host $proxy_host; client_max_body_size 400m; client_body_buffer_size 128k; proxy_buffering off; proxy_connect_timeout 3600; proxy_send_timeout 3600; proxy_read_timeout 3600; proxy_buffer_size 8k; proxy_buffers 8 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } } Если пытаться сделать pull не через nginx а напрямую всё работает. Пробовал так же прокинуть порт на шлюзе, тоже работает. Не работает только через nginx. nginx версии 1.2.8 родной из openbsd. Может есть хотя бы какой-нибудь способ протрассировать почему не пашет? Все эти опции в конфиге я уже добавлял по факту того что без них перестало работать, и с ними тоже не работает. Первое что увидел в гугле - large_client_header_buffers, менял в разных вариациях - ничего не помогло. Вот и понеслось.. Заранее спасибо за ответы Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239332,239332#msg-239332 From postmaster at softsearch.ru Mon May 20 09:01:53 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 20 May 2013 13:01:53 +0400 Subject: =?UTF-8?B?UmVbMl06INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0LLQsNC70LjQtNCw0YY=?= =?UTF-8?B?0LjQuCDQuNC80LXQvSDQsiBzZXJ2ZXJfbmFtZQ==?= In-Reply-To: <512C7B52.20504@kopeyko.ru> References: <548332593.20130226003324@mtu-net.ru> <74760879.20130226010405@mtu-net.ru> <512C52CC.9020402@kopeyko.ru> <1006210107.20130226113827@softsearch.ru> <512C7B52.20504@kopeyko.ru> Message-ID: <1365847696.20130520130153@softsearch.ru> Здравствуйте, Andrey. Как-то зимой я писал: > Очевидно можно ожидать, доменов photo, car, home, pet, cat, dog, > pony, fish и т.д. пока все слова не займут на всех языках. > Сергей Пантелеевич в замедленном варианте. Всё даже хуже, чем ожидалось: http://roem.ru/2013/05/20/addednews71939/ -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Mon May 20 11:04:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 20 May 2013 15:04:59 +0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC00L7QvNC70LXQvdC40LUg0LzQvtC00YPQu9GPINC+INGC0L4=?= =?UTF-8?B?0LwsINGH0YLQviDRgdC10YHRgdC40Y8g0LfQsNCy0LXRgNGI0LjQu9Cw0YE=?= =?UTF-8?B?0Yw=?= In-Reply-To: <0d59a7bc7aec51333eb6e90776945cce.NginxMailingListRussian@forum.nginx.org> References: <0d59a7bc7aec51333eb6e90776945cce.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130520110459.GA69760@mdounin.ru> Hello! On Sat, May 18, 2013 at 05:17:00AM -0400, megalodon wrote: > Всем доброго дня. > > Пишу модуль под nginx. > > Управление передается модулю, когда прилетает request и наступает > соответсвующая фаза обработки. Но, что если запрос не прилетел, а сессия > закрылась по тайм-ауту со стороны nginx либо от клиента явно прилетел FIN > или RST? Как при наступлении такого события можно передать упраление в > модуль? Если от клиента хоть что-то пришло - то будут вызваны обработчики фазы логгирования, NGX_HTTP_LOG_PHASE. Если клиент совсем ничего не присылал - то никак. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon May 20 12:50:47 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 20 May 2013 16:50:47 +0400 Subject: =?UTF-8?Q?Re=3A_400_Bad_Request_=D0=B2_Mercurial?= In-Reply-To: <7c004a7660960d0c9b08acdedfce2146.NginxMailingListRussian@forum.nginx.org> References: <7c004a7660960d0c9b08acdedfce2146.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130520125047.GC69760@mdounin.ru> Hello! On Mon, May 20, 2013 at 12:31:10AM -0400, kasak wrote: > Имеется репозиторий на меркуриале, работает через Apache на внутреннем > сервере, nginx стоит на шлюзе и проксирует запросы на внутренний сервер. С > определённого момента стало невозможным через nginx сделать pull, хотя clone > работает. При попытке сделать pull получаем 400:bad request. > > В error.log ничего, вот конфиг: > > server { > listen 80; > server_name hg.somesite.ru; > large_client_header_buffers 4 128k; > location / { > proxy_pass http://al-dabaran; > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header X-Host $http_host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header Proxy-host $proxy_host; > client_max_body_size 400m; > client_body_buffer_size 128k; > proxy_buffering off; > proxy_connect_timeout 3600; > proxy_send_timeout 3600; > proxy_read_timeout 3600; > proxy_buffer_size 8k; > proxy_buffers 8 32k; > proxy_busy_buffers_size 64k; > proxy_temp_file_write_size 64k; > } > > } > > Если пытаться сделать pull не через nginx а напрямую всё работает. Пробовал > так же прокинуть порт на шлюзе, тоже работает. Не работает только через > nginx. nginx версии 1.2.8 родной из openbsd. > Может есть хотя бы какой-нибудь способ протрассировать почему не пашет? > Все эти опции в конфиге я уже добавлял по факту того что без них перестало > работать, и с ними тоже не работает. Первое что увидел в гугле - > large_client_header_buffers, менял в разных вариациях - ничего не помогло. > Вот и понеслось.. > Заранее спасибо за ответы Если 400 Bad Request возвращает nginx - в error log'е на уровне info будет указана причина. Поставьте уровень логгирования error_log'у в info - станет понятнее в чём конкретно проблема. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon May 20 17:10:44 2013 From: nginx-forum at nginx.us (Vipper) Date: Mon, 20 May 2013 13:10:44 -0400 Subject: /index.php?do=register = deny all Message-ID: <745eea94b4d35d9c9a7c9d8a06550558.NginxMailingListRussian@forum.nginx.org> Доброго времени суток. Поскажите пожалуйска как правильно будет выглядеть конфиг чтобы закрыть доступ вот к таким url: 1- www.site.ru/index.php?do=register 2- www.site.ru/?do=register Что-то я совсем запутался и ни одно решение не заработало :( Заранее спасибо за помощь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239349,239349#msg-239349 From nginx-forum at nginx.us Tue May 21 06:29:49 2013 From: nginx-forum at nginx.us (kasak) Date: Tue, 21 May 2013 02:29:49 -0400 Subject: =?UTF-8?Q?Re=3A_400_Bad_Request_=D0=B2_Mercurial?= In-Reply-To: <20130520125047.GC69760@mdounin.ru> References: <20130520125047.GC69760@mdounin.ru> Message-ID: <96ada64f77445bb80890dd39afeec527.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Mon, May 20, 2013 at 12:31:10AM -0400, kasak wrote: > > > Имеется репозиторий на меркуриале, работает через Apache на > внутреннем > > сервере, nginx стоит на шлюзе и проксирует запросы на внутренний > сервер. С > > определённого момента стало невозможным через nginx сделать pull, > хотя clone > > работает. При попытке сделать pull получаем 400:bad request. > > > > В error.log ничего, вот конфиг: > > > > server { > > listen 80; > > server_name hg.somesite.ru; > > large_client_header_buffers 4 128k; > > location / { > > proxy_pass http://al-dabaran; > > proxy_redirect off; > > proxy_set_header Host $host; > > proxy_set_header X-Host $http_host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_set_header Proxy-host $proxy_host; > > client_max_body_size 400m; > > client_body_buffer_size 128k; > > proxy_buffering off; > > proxy_connect_timeout 3600; > > proxy_send_timeout 3600; > > proxy_read_timeout 3600; > > proxy_buffer_size 8k; > > proxy_buffers 8 32k; > > proxy_busy_buffers_size 64k; > > proxy_temp_file_write_size 64k; > > } > > > > } > > > > Если пытаться сделать pull не через nginx а напрямую всё работает. > Пробовал > > так же прокинуть порт на шлюзе, тоже работает. Не работает только > через > > nginx. nginx версии 1.2.8 родной из openbsd. > > Может есть хотя бы какой-нибудь способ протрассировать почему не > пашет? > > Все эти опции в конфиге я уже добавлял по факту того что без них > перестало > > работать, и с ними тоже не работает. Первое что увидел в гугле - > > large_client_header_buffers, менял в разных вариациях - ничего не > помогло. > > Вот и понеслось.. > > Заранее спасибо за ответы > > Если 400 Bad Request возвращает nginx - в error log'е на уровне > info будет указана причина. Поставьте уровень логгирования > error_log'у в info - станет понятнее в чём конкретно проблема. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Я пробовал выставлять debug, там только client closed connection Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239332,239372#msg-239372 From onokonem at gmail.com Tue May 21 06:43:46 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 21 May 2013 10:43:46 +0400 Subject: =?UTF-8?Q?Re=3A_400_Bad_Request_=D0=B2_Mercurial?= In-Reply-To: <96ada64f77445bb80890dd39afeec527.NginxMailingListRussian@forum.nginx.org> References: <20130520125047.GC69760@mdounin.ru> <96ada64f77445bb80890dd39afeec527.NginxMailingListRussian@forum.nginx.org> Message-ID: > Я пробовал выставлять debug, там только client closed connection Тогда это, скорее всего, и есть причина From nginx-forum at nginx.us Tue May 21 07:03:16 2013 From: nginx-forum at nginx.us (kasak) Date: Tue, 21 May 2013 03:03:16 -0400 Subject: =?UTF-8?Q?Re=3A_400_Bad_Request_=D0=B2_Mercurial?= In-Reply-To: References: Message-ID: <16ce8791dce84a5694562042f2f964c7.NginxMailingListRussian@forum.nginx.org> Daniel Podolsky Wrote: ------------------------------------------------------- > > Я пробовал выставлять debug, там только client closed connection > Тогда это, скорее всего, и есть причина > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Нет, это не причина. Вот лог: 2013/05/21 10:59:32 [info] 29253#0: *215 kevent() reported that client 192.168.3.119 closed keepalive connection 2013/05/21 10:59:32 [info] 29253#0: *221 kevent() reported that client 192.168.3.119 closed keepalive connection Работало с десяток человек с кодом, всё было прекрасно, но вот однажды шлёп: 400 bad request, у всех, и это при условии что ничего с настройками я не делал, всё просто перестало работать Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239332,239374#msg-239374 From vbart at nginx.com Tue May 21 09:58:00 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 21 May 2013 13:58:00 +0400 Subject: =?UTF-8?Q?Re=3A_400_Bad_Request_=D0=B2_Mercurial?= In-Reply-To: <16ce8791dce84a5694562042f2f964c7.NginxMailingListRussian@forum.nginx.org> References: <16ce8791dce84a5694562042f2f964c7.NginxMailingListRussian@forum.nginx.org> Message-ID: <201305211358.00752.vbart@nginx.com> On Tuesday 21 May 2013 11:03:16 kasak wrote: > Daniel Podolsky Wrote: > ------------------------------------------------------- > > > > Я пробовал выставлять debug, там только client closed connection > > > > Тогда это, скорее всего, и есть причина > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Нет, это не причина. Верно. Это не причина, поскольку 400-ую ошибку возвращает сам Mercurial. Если бы это делал nginx, то об этом были бы записи в логе, а их у вас нет. > Вот лог: > 2013/05/21 10:59:32 [info] 29253#0: *215 kevent() reported that client > 192.168.3.119 closed keepalive connection > 2013/05/21 10:59:32 [info] 29253#0: *221 kevent() reported that client > 192.168.3.119 closed keepalive connection > Эти сообщения не являются ошибкой и не имеют отношения к 400-ому ответу. -- Валентин Бартенев http://nginx.org/en/donation.html > Работало с десяток человек с кодом, всё было прекрасно, но вот однажды > шлёп: 400 bad request, у всех, и это при условии что ничего с настройками > я не делал, всё просто перестало работать > From nginx-forum at nginx.us Wed May 22 00:14:03 2013 From: nginx-forum at nginx.us (locojohn) Date: Tue, 21 May 2013 20:14:03 -0400 Subject: /index.php?do=register = deny all In-Reply-To: <745eea94b4d35d9c9a7c9d8a06550558.NginxMailingListRussian@forum.nginx.org> References: <745eea94b4d35d9c9a7c9d8a06550558.NginxMailingListRussian@forum.nginx.org> Message-ID: Наверное, вы этого не ждёте, но правильнее всего это было бы сделать в файле index.php: Андрей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239349,239403#msg-239403 From vbart at nginx.com Wed May 22 01:23:43 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 22 May 2013 05:23:43 +0400 Subject: /index.php?do=register = deny all In-Reply-To: <745eea94b4d35d9c9a7c9d8a06550558.NginxMailingListRussian@forum.nginx.org> References: <745eea94b4d35d9c9a7c9d8a06550558.NginxMailingListRussian@forum.nginx.org> Message-ID: <201305220523.43464.vbart@nginx.com> On Monday 20 May 2013 21:10:44 Vipper wrote: > Доброго времени суток. > Поскажите пожалуйска как правильно будет выглядеть конфиг чтобы закрыть > доступ вот к таким url: > 1- www.site.ru/index.php?do=register > 2- www.site.ru/?do=register > > Что-то я совсем запутался и ни одно решение не заработало :( > Заранее спасибо за помощь. > if ($arg_do = register) { return 403; } Reference: - http://nginx.org/r/if/ru - http://nginx.org/r/return/ru -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed May 22 03:03:19 2013 From: nginx-forum at nginx.us (Victor) Date: Tue, 21 May 2013 23:03:19 -0400 Subject: =?UTF-8?B?0J/QsNC00LDQtdGCIG5naW54?= Message-ID: nginx version: nginx/1.4.1 built by gcc 4.2.1 20070719 [FreeBSD] TLS SNI support enabled configure arguments: --prefix=/home/web/dian/nginx --sbin-path=/home/web/dian/nginx/ --conf-path=/home/web/dian/nginx/nginx.conf --pid-path=/home/web/dian/nginx/nginx.pid --with-pcre=../pcre-8.32 --with-zlib=../zlib-1.2.7 --with-file-aio --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --without-poll_module --without-select_module --without-http_charset_module --without-http_ssi_module --without-http_userid_module --without-http_access_module --without-http_autoindex_module --without-http_geo_module --without-http_map_module --without-http_split_clients_module --without-http_referer_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --without-http_limit_req_module --without-http_empty_gif_module --without-http_browser_module --without-http_upstream_ip_hash_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `nginx'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.5...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /usr/lib/libssl.so.6...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 ngx_palloc_large (pool=0x8010e6000, size=Variable "size" is not available. ) at src/core/ngx_palloc.c:247 247 large->alloc = p; (gdb) bt #0 ngx_palloc_large (pool=0x8010e6000, size=Variable "size" is not available. ) at src/core/ngx_palloc.c:247 #1 0x00000000004085fb in ngx_palloc (pool=0x8010e6000, size=16) at src/core/ngx_palloc.c:142 #2 0x00000000004494b2 in ngx_http_upstream_process_header (r=0x8010e6050, u=0x80118c120) at src/http/ngx_http_upstream.c:1563 #3 0x0000000000447308 in ngx_http_upstream_handler (ev=Variable "ev" is not available. ) at src/http/ngx_http_upstream.c:969 #4 0x000000000041d0da in ngx_event_process_posted (cycle=Variable "cycle" is not available. ) at src/event/ngx_event_posted.c:40 #5 0x000000000041cf7d in ngx_process_events_and_timers (cycle=0x80105a050) at src/event/ngx_event.c:276 #6 0x0000000000423039 in ngx_worker_process_cycle (cycle=0x80105a050, data=Variable "data" is not available. ) at src/os/unix/ngx_process_cycle.c:807 #7 0x0000000000421b57 in ngx_spawn_process (cycle=0x80105a050, proc=0x422f60 , data=0x3, name=0x478617 "worker process", respawn=-4) at src/os/unix/ngx_process.c:198 #8 0x0000000000422758 in ngx_start_worker_processes (cycle=0x80105a050, n=5, type=-4) at src/os/unix/ngx_process_cycle.c:362 #9 0x0000000000423bd4 in ngx_master_process_cycle (cycle=0x80105a050) at src/os/unix/ngx_process_cycle.c:249 #10 0x000000000040777b in main (argc=1, argv=Variable "argv" is not available. ) at src/core/nginx.c:412 (gdb) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239409,239409#msg-239409 From nginx-forum at nginx.us Wed May 22 07:03:54 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 03:03:54 -0400 Subject: =?UTF-8?B?NTAyLdC1INCyINC/0L7Rh9GC0YM=?= Message-ID: Нет ли готового решения на предмет раз в 15 минут сканировать access.log (в идеале - запомнив текущую позицию) , собрать все 502-е ( и/или другие - по выбору) и, если обнаружились, скинуть на e-mail. db Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239411#msg-239411 From chipitsine at gmail.com Wed May 22 07:11:17 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 22 May 2013 13:11:17 +0600 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: мы через Lua отправляем (блокирующая операция), смотрите, насколько это применимо к вашей ситуации error_page 502 = @502; location / { ............ } location @502 { default_type 'text/plain'; content_by_lua ' local smtp = require("socket.smtp") from = "" rcpt = { "<7912xxxxxxx at sms.xxx.mts.ru>", "<7922xxxxxxx at sms.xgsm.ru>" } mesgt = { headers = { to = "xxx <7912xxxxxxx at sms.xxx.mts.ru>", to = "xxx <7922xxxxxxx at sms.xgsm.ru>", subject = "Houston, we have problem: 502 at http://xxx" } } r, e = smtp.send{ from = from, rcpt = rcpt, source = smtp.message(mesgt) }'; } 22 мая 2013 г., 13:03 пользователь Gaidamak написал: > Нет ли готового решения на предмет раз в 15 минут сканировать access.log (в > идеале - запомнив текущую позицию) , собрать все 502-е ( и/или другие - по > выбору) и, если обнаружились, скинуть на e-mail. > > db > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239411#msg-239411 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Wed May 22 07:27:00 2013 From: nginx-forum at nginx.us (vlastv) Date: Wed, 22 May 2013 03:27:00 -0400 Subject: =?UTF-8?B?0J7RgtC80LXQvdCwINC30LDQs9GA0YPQt9C60Lg=?= Message-ID: <9cd6950560f40407daeb85c1e9f4e4d6.NginxMailingListRussian@forum.nginx.org> Здравствуйте, я использую модуль nginx upload module для приема файлов от клиентов. Иногда, клиенты отменяют/обрывают загрузку файла в результате чего в лог файле я вижу записи 2013/05/22 11:19:24 [alert] 31157#0: *46890490 aborted uploading file "1369210694718.png" to "/srv/www/example.com/tmp/0053618913", dest file removed, client: 111.111.111.111, server: example.com, request: "POST /api/files/ HTTP/1.1", host: "example.com" Можно ли как то организовать, чтоб nginx "дернул" какой нибудь упл, для информирования backend о том, что загрузка файла была отменена? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239413,239413#msg-239413 From nginx-forum at nginx.us Wed May 22 07:34:27 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 03:34:27 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: <1b238590cdaeef066dc54cb3294bcf6f.NginxMailingListRussian@forum.nginx.org> Спасибо. А нет ли у кого чего-то подобного на перловке, перловый модуль есть во фрибсдшном порту, а Lua вроде как нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239414#msg-239414 From chipitsine at gmail.com Wed May 22 07:37:52 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 22 May 2013 13:37:52 +0600 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <1b238590cdaeef066dc54cb3294bcf6f.NginxMailingListRussian@forum.nginx.org> References: <1b238590cdaeef066dc54cb3294bcf6f.NginxMailingListRussian@forum.nginx.org> Message-ID: а тут говорят, что LUA есть: http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/nginx/Makefile?rev=1.392;content-type=text%2Fplain 22 мая 2013 г., 13:34 пользователь Gaidamak написал: > Спасибо. А нет ли у кого чего-то подобного на перловке, перловый модуль есть > во фрибсдшном порту, а Lua вроде как нет. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239414#msg-239414 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Wed May 22 07:56:03 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 03:56:03 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: О, точно есть. А как этот скрипт себя ведет в случае массового возникновения 502-х? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239416#msg-239416 From vadim.lazovskiy at gmail.com Wed May 22 08:08:16 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Wed, 22 May 2013 12:08:16 +0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: Здравствуйте. Не проще ли сваливать все 502 ошибки через error_page в один location. В нем определить custom-ный формат лога (дата, хост, запрос) и в режиме tail -f разбирать его как угодно. Никаких блокировок и зависимостей от сторонних модулей. 22 мая 2013 г., 11:56 пользователь Gaidamak написал: > О, точно есть. А как этот скрипт себя ведет в случае массового > возникновения > 502-х? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239411,239416#msg-239416 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed May 22 08:20:46 2013 From: nginx-forum at nginx.us (Vipper) Date: Wed, 22 May 2013 04:20:46 -0400 Subject: /index.php?do=register = deny all In-Reply-To: <201305220523.43464.vbart@nginx.com> References: <201305220523.43464.vbart@nginx.com> Message-ID: <9f0b93298b53e02981662ddf7330df0a.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Monday 20 May 2013 21:10:44 Vipper wrote: > > Доброго времени суток. > > Поскажите пожалуйска как правильно будет выглядеть конфиг чтобы > закрыть > > доступ вот к таким url: > > 1- www.site.ru/index.php?do=register > > 2- www.site.ru/?do=register > > > > Что-то я совсем запутался и ни одно решение не заработало :( > > Заранее спасибо за помощь. > > > > if ($arg_do = register) { > return 403; > } Спасибо, работает как нужно. А что такое $arg_do ? Я пробовал писать нечто похожее но используя $request_uri. > > Reference: > > - http://nginx.org/r/if/ru > - http://nginx.org/r/return/ru > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239349,239418#msg-239418 From sytar.alex at gmail.com Wed May 22 08:34:23 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 22 May 2013 12:34:23 +0400 Subject: /index.php?do=register = deny all In-Reply-To: <9f0b93298b53e02981662ddf7330df0a.NginxMailingListRussian@forum.nginx.org> References: <201305220523.43464.vbart@nginx.com> <9f0b93298b53e02981662ddf7330df0a.NginxMailingListRussian@forum.nginx.org> Message-ID: 22 мая 2013 г., 12:20 пользователь Vipper написал: > А что такое $arg_do ? Аргумент query_string с названием "do" - http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed May 22 08:35:37 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 04:35:37 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: <1f370aa9707fe920b00244df65f6ad5f.NginxMailingListRussian@forum.nginx.org> Это и вправду должно быть надежней. Не даст ли кто-нибудь наводку на пример такой обработки ошибок? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239419#msg-239419 From vbart at nginx.com Wed May 22 09:22:59 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 22 May 2013 13:22:59 +0400 Subject: =?UTF-8?B?UmU6INCf0LDQtNCw0LXRgiBuZ2lueA==?= In-Reply-To: References: Message-ID: <201305221322.59152.vbart@nginx.com> On Wednesday 22 May 2013 07:03:19 Victor wrote: > nginx version: nginx/1.4.1 > built by gcc 4.2.1 20070719 [FreeBSD] > TLS SNI support enabled > configure arguments: --prefix=/home/web/dian/nginx > --sbin-path=/home/web/dian/nginx/ > --conf-path=/home/web/dian/nginx/nginx.conf > --pid-path=/home/web/dian/nginx/nginx.pid --with-pcre=../pcre-8.32 > --with-zlib=../zlib-1.2.7 --with-file-aio --with-http_realip_module > --with-http_stub_status_module --with-http_ssl_module --without-poll_module > --without-select_module --without-http_charset_module > --without-http_ssi_module --without-http_userid_module > --without-http_access_module --without-http_autoindex_module > --without-http_geo_module --without-http_map_module > --without-http_split_clients_module --without-http_referer_module > --without-http_uwsgi_module --without-http_scgi_module > --without-http_memcached_module --without-http_limit_req_module > --without-http_empty_gif_module --without-http_browser_module > --without-http_upstream_ip_hash_module --without-mail_pop3_module > --without-mail_imap_module --without-mail_smtp_module > > > > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `nginx'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libcrypt.so.5...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /usr/lib/libssl.so.6...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 ngx_palloc_large (pool=0x8010e6000, size=Variable "size" is not > available. > ) at src/core/ngx_palloc.c:247 > 247 large->alloc = p; > (gdb) bt > #0 ngx_palloc_large (pool=0x8010e6000, size=Variable "size" is not > available. > ) at src/core/ngx_palloc.c:247 > #1 0x00000000004085fb in ngx_palloc (pool=0x8010e6000, size=16) at > src/core/ngx_palloc.c:142 > #2 0x00000000004494b2 in ngx_http_upstream_process_header (r=0x8010e6050, > u=0x80118c120) > at src/http/ngx_http_upstream.c:1563 > #3 0x0000000000447308 in ngx_http_upstream_handler (ev=Variable "ev" is > not available. > ) at src/http/ngx_http_upstream.c:969 > #4 0x000000000041d0da in ngx_event_process_posted (cycle=Variable "cycle" > is not available. > ) at src/event/ngx_event_posted.c:40 > #5 0x000000000041cf7d in ngx_process_events_and_timers (cycle=0x80105a050) > at src/event/ngx_event.c:276 > #6 0x0000000000423039 in ngx_worker_process_cycle (cycle=0x80105a050, > data=Variable "data" is not available. > ) at src/os/unix/ngx_process_cycle.c:807 > #7 0x0000000000421b57 in ngx_spawn_process (cycle=0x80105a050, > proc=0x422f60 , data=0x3, > name=0x478617 "worker process", respawn=-4) at > src/os/unix/ngx_process.c:198 > #8 0x0000000000422758 in ngx_start_worker_processes (cycle=0x80105a050, > n=5, type=-4) > at src/os/unix/ngx_process_cycle.c:362 > #9 0x0000000000423bd4 in ngx_master_process_cycle (cycle=0x80105a050) at > src/os/unix/ngx_process_cycle.c:249 > #10 0x000000000040777b in main (argc=1, argv=Variable "argv" is not > available. > ) at src/core/nginx.c:412 > (gdb) > Без конфигурации и debug-лога данный трейс мало информативен. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed May 22 10:49:40 2013 From: nginx-forum at nginx.us (Papa) Date: Wed, 22 May 2013 06:49:40 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <1f370aa9707fe920b00244df65f6ad5f.NginxMailingListRussian@forum.nginx.org> References: <1f370aa9707fe920b00244df65f6ad5f.NginxMailingListRussian@forum.nginx.org> Message-ID: logcheck может мониторить логи и отсылать все новые вхождения на почту. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239425#msg-239425 From anatoly at sonru.com Wed May 22 11:24:40 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Wed, 22 May 2013 12:24:40 +0100 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCDQt9Cw0LPRgNGD0LfQutC4?= In-Reply-To: <9cd6950560f40407daeb85c1e9f4e4d6.NginxMailingListRussian@forum.nginx.org> References: <9cd6950560f40407daeb85c1e9f4e4d6.NginxMailingListRussian@forum.nginx.org> Message-ID: On May 22, 2013, at 8:27 AM, vlastv wrote: > Здравствуйте, > > я использую модуль nginx upload module для приема файлов от клиентов. за последний месяц тема стороннего upload module поднималась несколько раз, автор этого модуля не оставил никакой надежды на поддержку и дальнейшую разработку > > Иногда, клиенты отменяют/обрывают загрузку файла в результате чего в лог > файле я вижу записи > > 2013/05/22 11:19:24 [alert] 31157#0: *46890490 aborted uploading file > "1369210694718.png" to "/srv/www/example.com/tmp/0053618913", dest file > removed, client: 111.111.111.111, server: example.com, request: "POST > /api/files/ HTTP/1.1", host: "example.com" > > Можно ли как то организовать, чтоб nginx "дернул" какой нибудь упл, для > информирования backend о том, что загрузка файла была отменена? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239413,239413#msg-239413 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Wed May 22 13:36:04 2013 From: nginx-forum at nginx.us (vlastv) Date: Wed, 22 May 2013 09:36:04 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCDQt9Cw0LPRgNGD0LfQutC4?= In-Reply-To: References: Message-ID: Anatoly Mikhailov Wrote: ------------------------------------------------------- > On May 22, 2013, at 8:27 AM, vlastv wrote: > > > Здравствуйте, > > > > я использую модуль nginx upload module для приема файлов от > клиентов. > > за последний месяц тема стороннего upload module поднималась несколько > раз, > автор этого модуля не оставил никакой надежды на поддержку и > дальнейшую > разработку > это я и по гитхабу вижу, я хотел бы все же получить ответ на свой вопрос:) > > > > Иногда, клиенты отменяют/обрывают загрузку файла в результате чего в > лог > > файле я вижу записи > > > > 2013/05/22 11:19:24 [alert] 31157#0: *46890490 aborted uploading > file > > "1369210694718.png" to "/srv/www/example.com/tmp/0053618913", dest > file > > removed, client: 111.111.111.111, server: example.com, request: > "POST > > /api/files/ HTTP/1.1", host: "example.com" > > > > Можно ли как то организовать, чтоб nginx "дернул" какой нибудь упл, > для > > информирования backend о том, что загрузка файла была отменена? > > > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239413,239413#msg-239413 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239413,239428#msg-239428 From ufaweb at gmail.com Wed May 22 13:43:07 2013 From: ufaweb at gmail.com (=?UTF-8?B?0KDRg9GB0LvQsNC9INCo0LDRgNC40L/QvtCy?=) Date: Wed, 22 May 2013 19:43:07 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCDQt9Cw0LPRgNGD0LfQutC4?= In-Reply-To: References: Message-ID: Есть такая балалайка: http://wiki.nginx.org/HttpUploadProgressModule которая позволяет опрашивать (через http json(p)'ом) состояние загрузки (starting/uploading/error/done). 22 мая 2013 г., 19:36 пользователь vlastv написал: > Anatoly Mikhailov Wrote: > ------------------------------------------------------- >> On May 22, 2013, at 8:27 AM, vlastv wrote: >> >> > Здравствуйте, >> > >> > я использую модуль nginx upload module для приема файлов от >> клиентов. >> >> за последний месяц тема стороннего upload module поднималась несколько >> раз, >> автор этого модуля не оставил никакой надежды на поддержку и >> дальнейшую >> разработку >> > > это я и по гитхабу вижу, я хотел бы все же получить ответ на свой вопрос:) > >> > >> > Иногда, клиенты отменяют/обрывают загрузку файла в результате чего в >> лог >> > файле я вижу записи >> > >> > 2013/05/22 11:19:24 [alert] 31157#0: *46890490 aborted uploading >> file >> > "1369210694718.png" to "/srv/www/example.com/tmp/0053618913", dest >> file >> > removed, client: 111.111.111.111, server: example.com, request: >> "POST >> > /api/files/ HTTP/1.1", host: "example.com" >> > >> > Можно ли как то организовать, чтоб nginx "дернул" какой нибудь упл, >> для >> > информирования backend о том, что загрузка файла была отменена? >> > >> > Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,239413,239413#msg-239413 >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239413,239428#msg-239428 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Шарипов Руслан. Руководитель отдела разработки и сопровождения программного обеспечения ОАО "Уфанет". Контактная информация: google+: http://gplus.to/ruslan jid: serafim at jabber.ufanet.ru wave: ufaweb at googlewave.com skype: ufaweb phone: +7(917)4775460 vkontakte: http://vkontakte.ru/ufaweb myspace: http://www.myspace.com/ufaweb facebook: http://facebook.com/sharipov linkedin: http://www.linkedin.com/in/ufaweb twitter: http://twitter.com/ufaweb From nginx-forum at nginx.us Wed May 22 13:59:00 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 09:59:00 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: References: Message-ID: <42248018284aa83ba8f6745f66cc6a6b.NginxMailingListRussian@forum.nginx.org> Попробовал потренироваться на 400-х error_page 400 = @400; location @400 { access_log /var/log/nginx-400.log custom_db; } В логфайле пусто, хотя 400-х по факту полно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239433#msg-239433 From mdounin at mdounin.ru Wed May 22 14:14:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 22 May 2013 18:14:34 +0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <42248018284aa83ba8f6745f66cc6a6b.NginxMailingListRussian@forum.nginx.org> References: <42248018284aa83ba8f6745f66cc6a6b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130522141433.GG69760@mdounin.ru> Hello! On Wed, May 22, 2013 at 09:59:00AM -0400, Gaidamak wrote: > Попробовал потренироваться на 400-х > > error_page 400 = @400; > > location @400 { > > access_log /var/log/nginx-400.log custom_db; > > } > > В логфайле пусто, хотя 400-х по факту полно. У вас при попытке отдать error_page, скорее всего, случается ещё одна ошибка (вероятно - 404), и видимо тоже где-то обрабатывается (recursive_error_pages включены?). Если настоящую страницу ошибки класть не хочется, а хочется отдать именно встроенную, то можно так: error_page 400 = @400; location @400 { access_log /tmp/nginx-400.log; error_page 418 /just_to_clear_other_error_pages; return 400; } -- Maxim Dounin http://nginx.org/en/donation.html From slava.kokorin at gmail.com Wed May 22 14:24:16 2013 From: slava.kokorin at gmail.com (Slava Kokorin) Date: Wed, 22 May 2013 18:24:16 +0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <42248018284aa83ba8f6745f66cc6a6b.NginxMailingListRussian@forum.nginx.org> References: <42248018284aa83ba8f6745f66cc6a6b.NginxMailingListRussian@forum.nginx.org> Message-ID: 22 мая 2013 г., 17:59 пользователь Gaidamak написал: > Попробовал потренироваться на 400-х > > error_page 400 = @400; > > location @400 { > > access_log /var/log/nginx-400.log custom_db; > > } > > В логфайле пусто, хотя 400-х по факту полно. > Если я не ошибаюсь, то 400-е ошибки генерируются в первом блоке server?? {} для заданных IP:port, т.к. на момент генерации 400 ошибки не известен server_name Так что причина может быть и в этом если у вас общий access_log > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239411,239433#msg-239433 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Regards, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed May 22 14:59:01 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Wed, 22 May 2013 10:59:01 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <20130522141433.GG69760@mdounin.ru> References: <20130522141433.GG69760@mdounin.ru> Message-ID: А proxy_intercept_errors должна быть в каком положении? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239439#msg-239439 From nginx-forum at nginx.us Wed May 22 17:51:46 2013 From: nginx-forum at nginx.us (vlastv) Date: Wed, 22 May 2013 13:51:46 -0400 Subject: resumable upload In-Reply-To: <9310393640.20130514100144@softsearch.ru> References: <9310393640.20130514100144@softsearch.ru> Message-ID: <1dd5838cd163cd3fdba6233b233b2d0b.NginxMailingListRussian@forum.nginx.org> Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Dmitry. > > > Сложилась не очень приятная для многих ситуация в связи с > > upload-модулем и его неработоспособностью в свежих версиях nginx. > > В частности мы используем модуль в продакшене практически с самого > > появления модуля, и уже более двух лет используем его фичу resumable > > upload. На наших нагрузках использование модуля более чем оправдано, > > также как и оправдано использование дозагрузки в связи с большими > > размерами загружаемых файлов. > > Я сильно опасаюсь, что когда политика нашей компании вынудит > > обновиться до свежей версии nginx, у меня не будет никакой замены > > для upload-модуля (client_body_in_file_only ни разу не полноценная > > замена). > > > Поэтому, думаю многие были бы рады услышать ответ Nginx Inc. по > > поводу дальнейшей судьбы этого модуля, и request body-фильтров в > > частности, т.к. насколько я понимаю именно с их помощью можно будет > > легально реализовать такой же функционал. > > Если так сильно нужен модуль, то почему бы не проспонсировать его > доработку? У меня была подобная ситуация с самописным модулем и всё > прекрасно разрешилось. Цена вопроса? > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237896,239432#msg-239432 From nginx-forum at nginx.us Wed May 22 17:52:07 2013 From: nginx-forum at nginx.us (Papa) Date: Wed, 22 May 2013 13:52:07 -0400 Subject: =?UTF-8?B?UmU6INCa0YDQvtGB0YHQtNC+0LzQtdC90L3QsNGPINCw0LLRgtC+0YDQuNC30LA=?= =?UTF-8?B?0YbQuNGPINGB0YDQtdC00YHRgtCw0LLQvNC4IG5naW54?= In-Reply-To: References: Message-ID: Спасибо, ваш способ помог. Переиначил конфиг с выносом if (!-e $request_filename) { в location / и проблема разрешилась. Иногда нужен свежий взгляд, чтобы заметить очевидное)) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,238862,239444#msg-239444 From nginx-forum at nginx.us Thu May 23 06:28:23 2013 From: nginx-forum at nginx.us (Gaidamak) Date: Thu, 23 May 2013 02:28:23 -0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <20130522141433.GG69760@mdounin.ru> References: <20130522141433.GG69760@mdounin.ru> Message-ID: <25801c0df6675345ac76c35c26e0b92d.NginxMailingListRussian@forum.nginx.org> Перенес обработку 400 в блок сервера по дефолту. server { server_tokens off; listen 80 accept_filter=httpready; recursive_error_pages on; error_page 400 = @400; location @400 { access_log /var/log/nginx-400.log custom_db; error_page 418 /empty; return 400; } location / { access_log off; empty_gif; } } include sites/*.conf; } Не работает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239411,239458#msg-239458 From vadim.lazovskiy at gmail.com Thu May 23 06:39:09 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 23 May 2013 10:39:09 +0400 Subject: =?UTF-8?B?UmU6IDUwMi3QtSDQsiDQv9C+0YfRgtGD?= In-Reply-To: <25801c0df6675345ac76c35c26e0b92d.NginxMailingListRussian@forum.nginx.org> References: <20130522141433.GG69760@mdounin.ru> <25801c0df6675345ac76c35c26e0b92d.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. У вас accept_filter не подпускает плохие запросы к nginx-y. И по данному конфигу нельзя утверждать, что это сервер по-умолчанию. 2013/5/23 Gaidamak > Перенес обработку 400 в блок сервера по дефолту. > > server { > server_tokens off; > listen 80 accept_filter=httpready; > recursive_error_pages on; > > error_page 400 = @400; > > location @400 { > access_log /var/log/nginx-400.log custom_db; > error_page 418 /empty; > return 400; > } > location / > { > access_log off; > empty_gif; > } > } > > > include sites/*.conf; > } > > Не работает. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239411,239458#msg-239458 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu May 23 10:59:57 2013 From: nginx-forum at nginx.us (F1restorm) Date: Thu, 23 May 2013 06:59:57 -0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCDQvtGC0LLQtdGC0L7QsiDQvtGCINCx0Y0=?= =?UTF-8?B?0LrRjdC90LTQsA==?= In-Reply-To: References: Message-ID: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> Мне пришлось вернуться к решению описанной выше задачи, но как это сделать все еще не понятно. Попробую объяснить другими словами. Как сохранить или передать другому серверу ответ (заголовок и тело) от бэкэнда при определенных условиях (например, код ошибки 500+)? Вариант с отладочными логами не подойдет, т.к. при решении задачи потери производительности должны быть минимальными. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,233749,239469#msg-239469 From onokonem at gmail.com Thu May 23 12:18:07 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 23 May 2013 16:18:07 +0400 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCDQvtGC0LLQtdGC0L7QsiDQvtGCINCx0Y0=?= =?UTF-8?B?0LrRjdC90LTQsA==?= In-Reply-To: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> References: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> Message-ID: > Как сохранить или передать другому серверу ответ (заголовок и тело) от > бэкэнда при определенных условиях (например, код ошибки 500+)? Промежуточный прокси с формирователем ошибки? From postmaster at softsearch.ru Thu May 23 17:37:21 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 23 May 2013 21:37:21 +0400 Subject: =?UTF-8?B?UmVbMl06INCe0LHRgNCw0LHQvtGC0LrQsCDQvtGC0LLQtdGC0L7QsiDQvtGCINCx?= =?UTF-8?B?0Y3QutGN0L3QtNCw?= In-Reply-To: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> References: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> Message-ID: <191581314.20130523213721@softsearch.ru> Здравствуйте, F1restorm. > Как сохранить или передать другому серверу ответ (заголовок и тело) от > бэкэнда при определенных условиях (например, код ошибки 500+)? > Вариант с отладочными логами не подойдет, т.к. при решении задачи потери > производительности должны быть минимальными. Объедините бэкенды в апстрим и тогда если один бэкенд упадёт или вернёт ошибку, то запрос будет повторно отправлен на следующий бэкенд. -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Thu May 23 20:30:13 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 24 May 2013 00:30:13 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQntCx0YDQsNCx0L7RgtC60LAg0L7RgtCy0LXRgtC+0LIg0L4=?= =?UTF-8?B?0YIg0LHRjdC60Y3QvdC00LA=?= In-Reply-To: <191581314.20130523213721@softsearch.ru> References: <6a63cbcb07d8384805e3211e3122aad3.NginxMailingListRussian@forum.nginx.org> <191581314.20130523213721@softsearch.ru> Message-ID: > Объедините бэкенды в апстрим и тогда если один бэкенд упадёт или > вернёт ошибку, то запрос будет повторно отправлен на следующий бэкенд. не, TS надо получить тело ошибки, и обработать его чем-то. я, кстати, не знаю способа что-нибудь сделать с ответом бекенда на nginx. он же не буферизуется целиком, а уезжает к клиенту по мере получения. можно воткнуть еще один прокси на пути к бекенду, и делать работу на нем. From nginx-forum at nginx.us Fri May 24 09:35:06 2013 From: nginx-forum at nginx.us (fynloski) Date: Fri, 24 May 2013 05:35:06 -0400 Subject: =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3MgOA==?= Message-ID: Пытаюсь запустить nginx 1.4.1 на Windows 8. Выдает ошибку в логах: 2013/05/24 13:31:43 [emerg] 3272#2744: CreateFile() "C:\Users\Администратор\Downloads\nginx-1.4.1/conf/nginx.conf" failed (1113: No mapping for the Unicode character exists in the target multi-byte code page) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239503,239503#msg-239503 From mdounin at mdounin.ru Fri May 24 13:12:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 May 2013 17:12:03 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7QtCBXaW5kb3dzIDg=?= In-Reply-To: References: Message-ID: <20130524131203.GF69760@mdounin.ru> Hello! On Fri, May 24, 2013 at 05:35:06AM -0400, fynloski wrote: > Пытаюсь запустить nginx 1.4.1 на Windows 8. Выдает ошибку в логах: > > 2013/05/24 13:31:43 [emerg] 3272#2744: CreateFile() > "C:\Users\Администратор\Downloads\nginx-1.4.1/conf/nginx.conf" failed (1113: > No mapping for the Unicode character exists in the target multi-byte code > page) Сделайте так, чтобы в пути не было русских букв - должно заработать. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri May 24 14:26:13 2013 From: nginx-forum at nginx.us (romanvin) Date: Fri, 24 May 2013 10:26:13 -0400 Subject: =?UTF-8?B?0LTQvtCx0LDQstC+0YfQvdGL0Lkg0YTQsNC50Lsg0LIgaHR0cCBhZGRpdGlvbiBt?= =?UTF-8?B?b2R1bGU=?= Message-ID: <91e92d1aa3e7e4ff097d1fdfed089eae.NginxMailingListRussian@forum.nginx.org> Есть ли вариант, используя модуль ngx_http_addition_module, указывать в значении URI веб адрес (URL, например http/site.ru/pluscode.html) либо задавать путь к добавочному файлу который лежал бы в универсальном хранилище, например в /root/nginx/pluscode.html Сейчас как я понимаю, он может лежать только в директории сайта вида /home/user/public_html/pluscode.html и ни в каком другом месте. варианты вида add_before_body http://site.ru/pluscode.html add_before_body /home/nginx/pluscode.html не срабатывают. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239515,239515#msg-239515 From vbart at nginx.com Fri May 24 14:32:51 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 24 May 2013 18:32:51 +0400 Subject: =?UTF-8?B?UmU6INC00L7QsdCw0LLQvtGH0L3Ri9C5INGE0LDQudC7INCyIGh0dHAgYWRkaXRp?= =?UTF-8?B?b24gbW9kdWxl?= In-Reply-To: <91e92d1aa3e7e4ff097d1fdfed089eae.NginxMailingListRussian@forum.nginx.org> References: <91e92d1aa3e7e4ff097d1fdfed089eae.NginxMailingListRussian@forum.nginx.org> Message-ID: <201305241832.51194.vbart@nginx.com> On Friday 24 May 2013 18:26:13 romanvin wrote: > Есть ли вариант, используя модуль ngx_http_addition_module, указывать в > значении URI веб адрес (URL, например http/site.ru/pluscode.html) либо > задавать путь к добавочному файлу который лежал бы в универсальном > хранилище, например в /root/nginx/pluscode.html > > Сейчас как я понимаю, он может лежать только в директории сайта вида > /home/user/public_html/pluscode.html > и ни в каком другом месте. > > варианты вида > add_before_body http://site.ru/pluscode.html > add_before_body /home/nginx/pluscode.html > > не срабатывают. > Почему? location = /pluscode.html { internal; root /home/nginx; } -- Валентин Бартенев http://nginx.org/en/donation.html From nikolaygrebnev at gmail.com Fri May 24 15:31:21 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Fri, 24 May 2013 19:31:21 +0400 Subject: =?UTF-8?B?0L/RgNC+0YjRgyDQv9C+0LzQvtGH0Ywg0YEgcmV3cml0ZQ==?= Message-ID: Добрый день. Прошу помочь с конфигурированием, не получается самому написать. Была программа на php, например login.php . Теперь ее переписали и она должна работать с другого апстрима и там иметь адрес /account/login. Но убрать ссылки на login.php не представляется возможным, и на него идут как GET так и POST запросы. Поэтому идеальное решение было бы такое (только вот не понимаю как написать) location /login.php { proxy_pass http://newupstream; proxy_redirect off; proxy_set_header Host $host; proxy_set_header Via $http_via; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; rewrite_log on; rewrite login.php => /account/login (пишу смысл, так не получается написать правильно :( . Ну или работает GET вариант, а POST не получается никак) } Заранее спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri May 24 17:05:34 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 24 May 2013 21:05:34 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBIHJld3JpdGU=?= In-Reply-To: References: Message-ID: <201305242105.34977.vbart@nginx.com> On Friday 24 May 2013 19:31:21 Nikolay Grebnev wrote: > Добрый день. > > Прошу помочь с конфигурированием, не получается самому написать. > Была программа на php, например login.php . Теперь ее переписали и она > должна работать с другого апстрима и там иметь адрес /account/login. Но > убрать ссылки на login.php не представляется возможным, и на него идут как > GET так и POST запросы. Поэтому идеальное решение было бы такое (только вот > не понимаю как написать) > > location /login.php { > proxy_pass http://newupstream; > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header Via $http_via; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > rewrite_log on; > > rewrite login.php => /account/login (пишу смысл, так не получается > написать правильно :( . Ну или работает GET вариант, а POST не получается > никак) > } > > Заранее спасибо. location = /login.php { proxy_pass http://newupstream/account/login; } Reference: http://nginx.org/r/proxy_pass/ru -- Валентин Бартенев http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri May 24 18:26:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 May 2013 22:26:59 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: References: Message-ID: <20130524182659.GJ69760@mdounin.ru> Hello! On Tue, Apr 23, 2013 at 03:01:11PM +0400, Aleksey Chirkin wrote: > Каждый день на основной сервер добавляется директория с кучей файлов > объемом несколько гигабайт. И пока она синхронизируется на другие сервера, > попытка доступа к файлам этой директории на синхронизируемых серверах > приводит к ошибке 403. upstream заканчивает попытки перебора серверов не > обработав этот код в proxy_next_upstream. Патч прилагается. -- Maxim Dounin http://nginx.org/en/donation.html -------------- next part -------------- # HG changeset patch # User Maxim Dounin # Date 1369419922 -14400 # Node ID da84998957c960b872a56408ec49a8dfc90039b0 # Parent ea41bba49e8a14db045b6fe8e896bb7b1be0d759 Upstream: http_403 support in proxy_next_upstream (*_next_upstream). The parameter is mostly identical to http_404, and is expected to be used in similar situations. The 403 code might be returned by a backend instead of 404 on initial sync of new directiries with rsync. See here for feature request and additional details: http://mailman.nginx.org/pipermail/nginx-ru/2013-April/050920.html diff --git a/src/http/modules/ngx_http_fastcgi_module.c b/src/http/modules/ngx_http_fastcgi_module.c --- a/src/http/modules/ngx_http_fastcgi_module.c +++ b/src/http/modules/ngx_http_fastcgi_module.c @@ -185,6 +185,7 @@ static ngx_conf_bitmask_t ngx_http_fast { ngx_string("invalid_header"), NGX_HTTP_UPSTREAM_FT_INVALID_HEADER }, { ngx_string("http_500"), NGX_HTTP_UPSTREAM_FT_HTTP_500 }, { ngx_string("http_503"), NGX_HTTP_UPSTREAM_FT_HTTP_503 }, + { ngx_string("http_403"), NGX_HTTP_UPSTREAM_FT_HTTP_403 }, { ngx_string("http_404"), NGX_HTTP_UPSTREAM_FT_HTTP_404 }, { ngx_string("updating"), NGX_HTTP_UPSTREAM_FT_UPDATING }, { ngx_string("off"), NGX_HTTP_UPSTREAM_FT_OFF }, diff --git a/src/http/modules/ngx_http_proxy_module.c b/src/http/modules/ngx_http_proxy_module.c --- a/src/http/modules/ngx_http_proxy_module.c +++ b/src/http/modules/ngx_http_proxy_module.c @@ -178,6 +178,7 @@ static ngx_conf_bitmask_t ngx_http_prox { ngx_string("http_502"), NGX_HTTP_UPSTREAM_FT_HTTP_502 }, { ngx_string("http_503"), NGX_HTTP_UPSTREAM_FT_HTTP_503 }, { ngx_string("http_504"), NGX_HTTP_UPSTREAM_FT_HTTP_504 }, + { ngx_string("http_403"), NGX_HTTP_UPSTREAM_FT_HTTP_403 }, { ngx_string("http_404"), NGX_HTTP_UPSTREAM_FT_HTTP_404 }, { ngx_string("updating"), NGX_HTTP_UPSTREAM_FT_UPDATING }, { ngx_string("off"), NGX_HTTP_UPSTREAM_FT_OFF }, diff --git a/src/http/modules/ngx_http_scgi_module.c b/src/http/modules/ngx_http_scgi_module.c --- a/src/http/modules/ngx_http_scgi_module.c +++ b/src/http/modules/ngx_http_scgi_module.c @@ -65,6 +65,7 @@ static ngx_conf_bitmask_t ngx_http_scgi_ { ngx_string("invalid_header"), NGX_HTTP_UPSTREAM_FT_INVALID_HEADER }, { ngx_string("http_500"), NGX_HTTP_UPSTREAM_FT_HTTP_500 }, { ngx_string("http_503"), NGX_HTTP_UPSTREAM_FT_HTTP_503 }, + { ngx_string("http_403"), NGX_HTTP_UPSTREAM_FT_HTTP_403 }, { ngx_string("http_404"), NGX_HTTP_UPSTREAM_FT_HTTP_404 }, { ngx_string("updating"), NGX_HTTP_UPSTREAM_FT_UPDATING }, { ngx_string("off"), NGX_HTTP_UPSTREAM_FT_OFF }, diff --git a/src/http/modules/ngx_http_uwsgi_module.c b/src/http/modules/ngx_http_uwsgi_module.c --- a/src/http/modules/ngx_http_uwsgi_module.c +++ b/src/http/modules/ngx_http_uwsgi_module.c @@ -78,6 +78,7 @@ static ngx_conf_bitmask_t ngx_http_uwsgi { ngx_string("invalid_header"), NGX_HTTP_UPSTREAM_FT_INVALID_HEADER }, { ngx_string("http_500"), NGX_HTTP_UPSTREAM_FT_HTTP_500 }, { ngx_string("http_503"), NGX_HTTP_UPSTREAM_FT_HTTP_503 }, + { ngx_string("http_403"), NGX_HTTP_UPSTREAM_FT_HTTP_403 }, { ngx_string("http_404"), NGX_HTTP_UPSTREAM_FT_HTTP_404 }, { ngx_string("updating"), NGX_HTTP_UPSTREAM_FT_UPDATING }, { ngx_string("off"), NGX_HTTP_UPSTREAM_FT_OFF }, diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c --- a/src/http/ngx_http_upstream.c +++ b/src/http/ngx_http_upstream.c @@ -369,6 +369,7 @@ static ngx_http_upstream_next_t ngx_htt { 502, NGX_HTTP_UPSTREAM_FT_HTTP_502 }, { 503, NGX_HTTP_UPSTREAM_FT_HTTP_503 }, { 504, NGX_HTTP_UPSTREAM_FT_HTTP_504 }, + { 403, NGX_HTTP_UPSTREAM_FT_HTTP_403 }, { 404, NGX_HTTP_UPSTREAM_FT_HTTP_404 }, { 0, 0 } }; @@ -3156,8 +3157,11 @@ ngx_http_upstream_next(ngx_http_request_ if (u->peer.sockaddr) { - if (ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_404) { + if (ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_403 + || ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_404) + { state = NGX_PEER_NEXT; + } else { state = NGX_PEER_FAILED; } @@ -3189,6 +3193,10 @@ ngx_http_upstream_next(ngx_http_request_ status = NGX_HTTP_INTERNAL_SERVER_ERROR; break; + case NGX_HTTP_UPSTREAM_FT_HTTP_403: + status = NGX_HTTP_FORBIDDEN; + break; + case NGX_HTTP_UPSTREAM_FT_HTTP_404: status = NGX_HTTP_NOT_FOUND; break; diff --git a/src/http/ngx_http_upstream.h b/src/http/ngx_http_upstream.h --- a/src/http/ngx_http_upstream.h +++ b/src/http/ngx_http_upstream.h @@ -24,10 +24,11 @@ #define NGX_HTTP_UPSTREAM_FT_HTTP_502 0x00000020 #define NGX_HTTP_UPSTREAM_FT_HTTP_503 0x00000040 #define NGX_HTTP_UPSTREAM_FT_HTTP_504 0x00000080 -#define NGX_HTTP_UPSTREAM_FT_HTTP_404 0x00000100 -#define NGX_HTTP_UPSTREAM_FT_UPDATING 0x00000200 -#define NGX_HTTP_UPSTREAM_FT_BUSY_LOCK 0x00000400 -#define NGX_HTTP_UPSTREAM_FT_MAX_WAITING 0x00000800 +#define NGX_HTTP_UPSTREAM_FT_HTTP_403 0x00000100 +#define NGX_HTTP_UPSTREAM_FT_HTTP_404 0x00000200 +#define NGX_HTTP_UPSTREAM_FT_UPDATING 0x00000400 +#define NGX_HTTP_UPSTREAM_FT_BUSY_LOCK 0x00000800 +#define NGX_HTTP_UPSTREAM_FT_MAX_WAITING 0x00001000 #define NGX_HTTP_UPSTREAM_FT_NOLIVE 0x40000000 #define NGX_HTTP_UPSTREAM_FT_OFF 0x80000000 @@ -35,6 +36,7 @@ |NGX_HTTP_UPSTREAM_FT_HTTP_502 \ |NGX_HTTP_UPSTREAM_FT_HTTP_503 \ |NGX_HTTP_UPSTREAM_FT_HTTP_504 \ + |NGX_HTTP_UPSTREAM_FT_HTTP_403 \ |NGX_HTTP_UPSTREAM_FT_HTTP_404) #define NGX_HTTP_UPSTREAM_INVALID_HEADER 40 From nikolaygrebnev at gmail.com Sat May 25 08:43:33 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Sat, 25 May 2013 12:43:33 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBIHJld3JpdGU=?= In-Reply-To: <201305242105.34977.vbart@nginx.com> References: <201305242105.34977.vbart@nginx.com> Message-ID: Валентин, огромное спасибо!!! 2013/5/24 Валентин Бартенев : > On Friday 24 May 2013 19:31:21 Nikolay Grebnev wrote: >> Добрый день. >> >> Прошу помочь с конфигурированием, не получается самому написать. >> Была программа на php, например login.php . Теперь ее переписали и она >> должна работать с другого апстрима и там иметь адрес /account/login. Но >> убрать ссылки на login.php не представляется возможным, и на него идут как >> GET так и POST запросы. Поэтому идеальное решение было бы такое (только вот >> не понимаю как написать) >> >> location /login.php { >> proxy_pass http://newupstream; >> proxy_redirect off; >> proxy_set_header Host $host; >> proxy_set_header Via $http_via; >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> rewrite_log on; >> >> rewrite login.php => /account/login (пишу смысл, так не получается >> написать правильно :( . Ну или работает GET вариант, а POST не получается >> никак) >> } >> >> Заранее спасибо. > > location = /login.php { > proxy_pass http://newupstream/account/login; > } > > Reference: > > http://nginx.org/r/proxy_pass/ru > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From sergey.kobzar at itcraft.org Sat May 25 17:25:12 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Sat, 25 May 2013 20:25:12 +0300 Subject: =?UTF-8?B?0L/QvtC00YHRgtCw0L3QvtCy0LrQsCDQsiByZWdleHA=?= Message-ID: <51A0F3F8.3070203@itcraft.org> Приветствую Есть location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { try_files /cache/$2/$1_$3_$4.jpg /index.php?pid=$1&width=$3&height=$4; } Вместо нужно подставить 00. Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. Временное решение - обьявить переменную и использовать ее: set $abc 00; ... /cache/$2$abc/$1_$3_$4.jpg но как-то это криво. Как правильно отделить нули от подстановки? Спасибо. From vbart at nginx.com Sun May 26 00:16:14 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 26 May 2013 04:16:14 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0LIgcmVnZXhw?= In-Reply-To: <51A0F3F8.3070203@itcraft.org> References: <51A0F3F8.3070203@itcraft.org> Message-ID: <201305260416.14471.vbart@nginx.com> On Saturday 25 May 2013 21:25:12 Sergey Kobzar wrote: > Приветствую > > Есть > > location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { > try_files /cache/$2/$1_$3_$4.jpg > /index.php?pid=$1&width=$3&height=$4; } > > Вместо нужно подставить 00. > > Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. [...] Почему вы так решили? -- Валентин Бартенев http://nginx.org/en/donation.html From sergey.kobzar at itcraft.org Sun May 26 10:51:48 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Sun, 26 May 2013 13:51:48 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0LIgcmVnZXhw?= In-Reply-To: <201305260416.14471.vbart@nginx.com> References: <51A0F3F8.3070203@itcraft.org> <201305260416.14471.vbart@nginx.com> Message-ID: <51A1E944.3050607@itcraft.org> On 05/26/13 03:16, Валентин Бартенев wrote: > On Saturday 25 May 2013 21:25:12 Sergey Kobzar wrote: >> Приветствую >> >> Есть >> >> location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { >> try_files /cache/$2/$1_$3_$4.jpg >> /index.php?pid=$1&width=$3&height=$4; } >> >> Вместо нужно подставить 00. >> >> Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. > [...] > > Почему вы так решили? Потому что пробовал с пол года назад на версии до 1.0. Точно деталей (версий) уже не помню. Думаете должно работать как ожидается на последних версиях? > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From vbart at nginx.com Sun May 26 15:36:02 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 26 May 2013 19:36:02 +0400 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0LIgcmVnZXhw?= In-Reply-To: <51A1E944.3050607@itcraft.org> References: <51A0F3F8.3070203@itcraft.org> <201305260416.14471.vbart@nginx.com> <51A1E944.3050607@itcraft.org> Message-ID: <201305261936.02143.vbart@nginx.com> On Sunday 26 May 2013 14:51:48 Sergey Kobzar wrote: > On 05/26/13 03:16, Валентин Бартенев wrote: > > On Saturday 25 May 2013 21:25:12 Sergey Kobzar wrote: > >> Приветствую > >> > >> Есть > >> > >> location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { > >> > >> try_files /cache/$2/$1_$3_$4.jpg > >> > >> /index.php?pid=$1&width=$3&height=$4; } > >> > >> Вместо нужно подставить 00. > >> > >> Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. > > > > [...] > > > > Почему вы так решили? > > Потому что пробовал с пол года назад на версии до 1.0. Точно деталей > (версий) уже не помню. > > Думаете должно работать как ожидается на последних версиях? > Парсер переменных различает только $1-$9 и, если я не ошибаюсь, так было всегда с момента появления такой поддержки. -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Sun May 26 16:23:24 2013 From: nginx-forum at nginx.us (megalodon) Date: Sun, 26 May 2013 12:23:24 -0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC00L7QvNC70LXQvdC40LUg0LzQvtC00YPQu9GPINC+INGC0L4=?= =?UTF-8?B?0LwsINGH0YLQviDRgdC10YHRgdC40Y8g0LfQsNCy0LXRgNGI0LjQu9Cw0YE=?= =?UTF-8?B?0Yw=?= In-Reply-To: <20130520110459.GA69760@mdounin.ru> References: <20130520110459.GA69760@mdounin.ru> Message-ID: <92e61280860b6d249368b35338a68717.NginxMailingListRussian@forum.nginx.org> У меня получилось так: 1. В модуле ngx_epoll_module.c добавил extern tcp_close_notification (ngx_connection_t *c); 2. В функции ngx_epoll_del_connection() вызываю tcp_close_notification(c); А функция tcp_close_notification() определена в моем модуле и ей видны все необходимые структуры данных. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239313,239544#msg-239544 From sergey.kobzar at itcraft.org Sun May 26 18:33:45 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Sun, 26 May 2013 21:33:45 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0LIgcmVnZXhw?= In-Reply-To: <201305261936.02143.vbart@nginx.com> References: <51A0F3F8.3070203@itcraft.org> <201305260416.14471.vbart@nginx.com> <51A1E944.3050607@itcraft.org> <201305261936.02143.vbart@nginx.com> Message-ID: <51A25589.9080400@itcraft.org> On 05/26/13 18:36, Валентин Бартенев wrote: > On Sunday 26 May 2013 14:51:48 Sergey Kobzar wrote: >> On 05/26/13 03:16, Валентин Бартенев wrote: >>> On Saturday 25 May 2013 21:25:12 Sergey Kobzar wrote: >>>> Приветствую >>>> >>>> Есть >>>> >>>> location ~ ^/(...(...)...)/(...)/(...)/[^/]*$ { >>>> >>>> try_files /cache/$2/$1_$3_$4.jpg >>>> >>>> /index.php?pid=$1&width=$3&height=$4; } >>>> >>>> Вместо нужно подставить 00. >>>> >>>> Вариант /cache/$200/$1_$3_$4.jpg естественно не проходит. >>> >>> [...] >>> >>> Почему вы так решили? >> >> Потому что пробовал с пол года назад на версии до 1.0. Точно деталей >> (версий) уже не помню. >> >> Думаете должно работать как ожидается на последних версиях? >> > > Парсер переменных различает только $1-$9 и, если я не ошибаюсь, так было > всегда с момента появления такой поддержки. ОК. Потестирую еще раз и отпишусь о резулттатах. Спасибо. > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum at nginx.us Mon May 27 07:56:10 2013 From: nginx-forum at nginx.us (john2do) Date: Mon, 27 May 2013 03:56:10 -0400 Subject: =?UTF-8?B?0LIg0L7Rh9C10YDQtdC00L3QvtC5INGA0LDQtyDQv9GA0L4g0YDQtdC00LjRgNC1?= =?UTF-8?B?0LrRgiDQvdCwINC00YDRg9Cz0L7QuSDQtNC+0LzQtdC9INC4INC30LDQvNC1?= =?UTF-8?B?0L3QsCDQsNGA0LPRg9C80LXQvdGC0LA=?= Message-ID: <7861788902f22be0934c28c3805404fe.NginxMailingListRussian@forum.nginx.org> Граждане! встречалась ссылка на пример конфигурации для 100500 (не шутка) редиректов с заменой аргументов через map не могу её найти, ткните носом или пример конфига? имеется три домена, перенесли форум с одного домена на другой. аргумент идэ форума изменился, хочется сделать красивее решение, нежели 100к иф-ов в локейшине вида: location /forum/message.php { if ($arg_id = 1167) { set $args id=2104; rewrite ^.+$ http://host-new.ru/forum/message.php permanent; } if ($args ~* id=1168(&|$)) { set $args id=2105; rewrite ^.+$ http://host-new.ru/forum/message.php permanent; } ... и еще 100-200к таких ифов. и второй (есть третий и четвертый) location /item/id.php { if ($arg_id = 11677) { set $args id=2204; rewrite ^.+$ http://host-new.ru/item/id.php permanent; } if ($arg_id = 11678) { set $args id=2205; rewrite ^.+$ http://host-new.ru/item/id.php permanent; } } подскажите красивое решение? а если еще и остальные пришедшие аргументы можно оставить - то и вовсе здорово будет Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239557,239557#msg-239557 From a.vasilishin at kpi.ua Mon May 27 10:16:28 2013 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 27 May 2013 13:16:28 +0300 Subject: =?UTF-8?B?0JfQsNC00LXRgNC20LrQuCDQv9GA0LggcHJveHlfY2FjaGUgKyBITFM=?= Message-ID: <51A3327C.6030407@kpi.ua> Всем привет! Ситуация такая, нгинкс с proxy_cache стоит перед FMS, и все хорошо, когда размер фрагмента больше 1Мб, кусок сразу отдается пользователю, когда размер меньше 1Мб, почему-то идет задержка 1с. Какой буфер можно/нужно подкрутить, чтобы исправить ситуацию? Конфиг такой: proxy_cache_path /megastorage/nginx/nginx_proxy_cache levels=1:2 keys_zone=two:256m inactive=10m max_size=570G; proxy_cache_key "$proxy_host$request_uri"; location ~* ^/(hds|vod|hls){ proxy_buffering on; proxy_pass http://127.0.0.1:8134; proxy_cache_min_uses 5; proxy_cache_valid 200 30m; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Accept-Encoding ""; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_cache_key "$proxy_host$request_uri"; proxy_cache two; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_404; proxy_temp_path /megastorage/nginx/proxy_temp 1 2; access_log off; expires 1d; proxy_read_timeout 10s; proxy_connect_timeout 10s; proxy_send_timeout 10s; error_page 500 502 503 504 =200 @checkstatus; } -------------- next part -------------- A non-text attachment was scrubbed... Name: 1908c772fd97[1].png Type: image/png Size: 148557 bytes Desc: not available URL: From citrin at citrin.ru Mon May 27 10:24:30 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 27 May 2013 14:24:30 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <51A3327C.6030407@kpi.ua> References: <51A3327C.6030407@kpi.ua> Message-ID: <51A3345E.90609@citrin.ru> On 05/27/13 14:16, Андрей Василишин wrote: > > Ситуация такая, нгинкс с proxy_cache стоит перед FMS, и все хорошо, когда размер > фрагмента больше 1Мб, кусок сразу отдается пользователю, когда размер меньше > 1Мб, почему-то идет задержка 1с. Добавьте $upstream_response_time в лог, чтобы видеть где задержка - между клиентом и nginx или между nginx и бэкендом. Ну и далее стоит поизучать tcpdump для такого медленного запроса. From anatoly at sonru.com Mon May 27 10:28:53 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 27 May 2013 11:28:53 +0100 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <51A3327C.6030407@kpi.ua> References: <51A3327C.6030407@kpi.ua> Message-ID: Проксирование перед медиа-сервером? Видео отдаете через HTTPS? Если да, то чем это лучше отдачи через модуль псевдостримминга nginx_mp4_module? Анатолий On May 27, 2013, at 11:16 AM, Андрей Василишин wrote: > Всем привет! > Ситуация такая, нгинкс с proxy_cache стоит перед FMS, и все хорошо, когда размер фрагмента больше 1Мб, кусок сразу отдается пользователю, когда размер меньше 1Мб, почему-то идет задержка 1с. Какой буфер можно/нужно подкрутить, чтобы исправить ситуацию? Конфиг такой: > > > proxy_cache_path /megastorage/nginx/nginx_proxy_cache levels=1:2 keys_zone=two:256m inactive=10m max_size=570G; > proxy_cache_key "$proxy_host$request_uri"; > > > location ~* ^/(hds|vod|hls){ > proxy_buffering on; > proxy_pass http://127.0.0.1:8134; > proxy_cache_min_uses 5; > proxy_cache_valid 200 30m; > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Accept-Encoding ""; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_cache_key "$proxy_host$request_uri"; > proxy_cache two; > proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_404; > proxy_temp_path /megastorage/nginx/proxy_temp 1 2; > access_log off; > expires 1d; > proxy_read_timeout 10s; > proxy_connect_timeout 10s; > proxy_send_timeout 10s; > error_page 500 502 503 504 =200 @checkstatus; > } > > <1908c772fd97[1].png>_______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From a.vasilishin at kpi.ua Mon May 27 10:32:07 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Mon, 27 May 2013 13:32:07 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: References: <51A3327C.6030407@kpi.ua> Message-ID: <51A33627.8090900@kpi.ua> 27.05.2013 13:28, Anatoly Mikhailov пишет: > Проксирование перед медиа-сервером? Видео отдаете через HTTPS? > Если да, то чем это лучше отдачи через модуль псевдостримминга nginx_mp4_module? > нет, не HTTPS, лучше тем, что это HLS, помимо экономии трафика (почти в 2 раза) еще делает задачу парсинга сложновыполнимой. From anatoly at sonru.com Mon May 27 10:41:28 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 27 May 2013 11:41:28 +0100 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <51A33627.8090900@kpi.ua> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> Message-ID: <4CFDE39B-AC9E-4B1A-B84D-A3435D717B20@sonru.com> On May 27, 2013, at 11:32 AM, Андрей Василишин wrote: > 27.05.2013 13:28, Anatoly Mikhailov пишет: >> Проксирование перед медиа-сервером? Видео отдаете через HTTPS? >> Если да, то чем это лучше отдачи через модуль псевдостримминга nginx_mp4_module? >> > нет, не HTTPS, лучше тем, что это HLS, помимо экономии трафика (почти в 2 раза) еще делает задачу парсинга сложновыполнимой. > интересно, за счет чего экономия трафика, такой уж большой оверхед у HTTP? Чем замеряли? HLS - работает через корпоративные фаерволы? > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nikolaygrebnev at gmail.com Mon May 27 10:58:45 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Mon, 27 May 2013 14:58:45 +0400 Subject: =?UTF-8?B?0L/RgNC+0YjRgyDQv9C+0LzQvtGH0Ywg0YEg0LrQtdGI0LjRgNC+0LLQsNC90Lg=?= =?UTF-8?B?0LXQvA==?= Message-ID: Добрый день. Не получается сделать кеширование для титульных страниц (виртуальных хостов много). В лог идет все время MISS. При этом в cache директорию что-то иногда записывается. по какому признаку для меня загадка (иногда как раз те вещи которые не должны записываться - например страницы отлогинивания, к счастью в ключе есть$request_uri поэтому это не мешается) . http { proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=default:30m max_size=1G; proxy_temp_path /usr/local/nginx/proxy 1 2; proxy_cache_use_stale error timeout invalid_header http_502; proxy_cache_bypass $cookie_phpbb2mysql_sid; proxy_no_cache $cookie_phpbb2mysql_sid; #эти 3 строки добавлены от отчаяния, но не помогли proxy_buffers 8 32k; proxy_buffer_size 64k; proxy_buffering On; ..... location = / { proxy_pass http://php; proxy_redirect off; proxy_set_header Host $host; proxy_set_header Via $http_via; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # index index.php; - убираение не помогло rewrite_log on; proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; proxy_cache default; proxy_cache_valid 200 300s; proxy_cache_key "$request_method|$host|$request_uri"; # proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; proxy_hide_header "Set-Cookie"; proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и нет из php когда нет сессии limit_conn addr 4; } Вот такой вот конфиг. Прошу помочь сделать чтобы кеширование заработало :) Николай -------------- next part -------------- An HTML attachment was scrubbed... URL: From sytar.alex at gmail.com Mon May 27 11:00:57 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Mon, 27 May 2013 15:00:57 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBINC60LXRiNC40YDQvtCy0LA=?= =?UTF-8?B?0L3QuNC10Lw=?= In-Reply-To: References: Message-ID: 27 мая 2013 г., 14:58 пользователь Nikolay Grebnev написал: > Добрый день. > > Не получается сделать кеширование для титульных страниц (виртуальных > хостов много). В лог идет все время MISS. При этом в cache директорию > что-то иногда записывается. по какому признаку для меня загадка (иногда как > раз те вещи которые не должны записываться - например страницы > отлогинивания, к счастью в ключе есть$request_uri поэтому это не мешается) > . > > http { > proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=default:30m > max_size=1G; > proxy_temp_path /usr/local/nginx/proxy 1 2; > proxy_cache_use_stale error timeout invalid_header http_502; > proxy_cache_bypass $cookie_phpbb2mysql_sid; > proxy_no_cache $cookie_phpbb2mysql_sid; > > #эти 3 строки добавлены от отчаяния, но не помогли > proxy_buffers 8 32k; > proxy_buffer_size 64k; > proxy_buffering On; > > > ..... > > location = / { > proxy_pass http://php; > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header Via $http_via; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > # index index.php; - убираение не помогло > rewrite_log on; > proxy_connect_timeout 300; > proxy_send_timeout 300; > proxy_read_timeout 300; > proxy_cache default; > proxy_cache_valid 200 300s; > proxy_cache_key "$request_method|$host|$request_uri"; > # proxy_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; > proxy_hide_header "Set-Cookie"; > proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и нет > из php когда нет сессии > limit_conn addr 4; > } > > > Вот такой вот конфиг. > Прошу помочь сделать чтобы кеширование заработало :) > > Николай > > При этом в папке /usr/local/nginx/cache что-нибудь появляется? В error_log что-нибудь на тему кеширования есть? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolaygrebnev at gmail.com Mon May 27 11:06:23 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Mon, 27 May 2013 15:06:23 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBINC60LXRiNC40YDQvtCy0LA=?= =?UTF-8?B?0L3QuNC10Lw=?= In-Reply-To: References: Message-ID: В error_log все чистенько В /usr/local/nginx/cache что-то ИНОГДА появляется (иногда тк запросов дофига, а записей там "по пальцам пересчитать") Перечислю те которые сейчас там KEY: GET|www.domain.ru |/?userlogout=100165958&sid=3c85d72b3aa90fe076c48a07564b3564 KEY: GET|www.domain.ru|/ KEY: GET|www.domain1.org|/ собственно, все :( 2013/5/27 Aleksandr Sytar > > > > 27 мая 2013 г., 14:58 пользователь Nikolay Grebnev < > nikolaygrebnev at gmail.com> написал: > > Добрый день. >> >> Не получается сделать кеширование для титульных страниц (виртуальных >> хостов много). В лог идет все время MISS. При этом в cache директорию >> что-то иногда записывается. по какому признаку для меня загадка (иногда как >> раз те вещи которые не должны записываться - например страницы >> отлогинивания, к счастью в ключе есть$request_uri поэтому это не мешается) >> . >> >> http { >> proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=default:30m >> max_size=1G; >> proxy_temp_path /usr/local/nginx/proxy 1 2; >> proxy_cache_use_stale error timeout invalid_header http_502; >> proxy_cache_bypass $cookie_phpbb2mysql_sid; >> proxy_no_cache $cookie_phpbb2mysql_sid; >> >> #эти 3 строки добавлены от отчаяния, но не помогли >> proxy_buffers 8 32k; >> proxy_buffer_size 64k; >> proxy_buffering On; >> >> >> ..... >> >> location = / { >> proxy_pass http://php; >> proxy_redirect off; >> proxy_set_header Host $host; >> proxy_set_header Via $http_via; >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> # index index.php; - убираение не помогло >> rewrite_log on; >> proxy_connect_timeout 300; >> proxy_send_timeout 300; >> proxy_read_timeout 300; >> proxy_cache default; >> proxy_cache_valid 200 300s; >> proxy_cache_key "$request_method|$host|$request_uri"; >> # proxy_cache_key >> "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; >> proxy_hide_header "Set-Cookie"; >> proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и нет >> из php когда нет сессии >> limit_conn addr 4; >> } >> >> >> Вот такой вот конфиг. >> Прошу помочь сделать чтобы кеширование заработало :) >> >> Николай >> >> > При этом в папке /usr/local/nginx/cache что-нибудь появляется? > В error_log что-нибудь на тему кеширования есть? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From myc at barev.net Mon May 27 11:53:01 2013 From: myc at barev.net (Eugene Mychlo) Date: Mon, 27 May 2013 15:53:01 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <51A33627.8090900@kpi.ua> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> Message-ID: <651334A6-03A9-4A34-9CF1-8C079809A727@barev.net> 27.05.2013, в 14:32, Андрей Василишин написал(а): > 27.05.2013 13:28, Anatoly Mikhailov пишет: >> Проксирование перед медиа-сервером? Видео отдаете через HTTPS? >> Если да, то чем это лучше отдачи через модуль псевдостримминга nginx_mp4_module? >> > нет, не HTTPS, лучше тем, что это HLS, помимо экономии трафика (почти в 2 раза) еще делает задачу парсинга сложновыполнимой. > > HLS в сравнении с HTTP PD (ngx_mp4_module) дает оверхед ~20-30% из-за паддинга в ts пакетах. Правда при активных сиках по ролику, этот оверхед нивелируется. Можно немного поподробнее про задачу парсинга? Фраза не совсем понятна. -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From a.vasilishin at kpi.ua Mon May 27 12:19:05 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Mon, 27 May 2013 15:19:05 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <4CFDE39B-AC9E-4B1A-B84D-A3435D717B20@sonru.com> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> <4CFDE39B-AC9E-4B1A-B84D-A3435D717B20@sonru.com> Message-ID: <51A34F39.2010101@kpi.ua> 27.05.2013 13:41, Anatoly Mikhailov пишет: > > On May 27, 2013, at 11:32 AM, Андрей Василишин wrote: > >> 27.05.2013 13:28, Anatoly Mikhailov пишет: >>> Проксирование перед медиа-сервером? Видео отдаете через HTTPS? >>> Если да, то чем это лучше отдачи через модуль псевдостримминга nginx_mp4_module? >>> >> нет, не HTTPS, лучше тем, что это HLS, помимо экономии трафика (почти в 2 раза) еще делает задачу парсинга сложновыполнимой. >> > > интересно, за счет чего экономия трафика, такой уж большой оверхед у HTTP? Чем замеряли? > HLS - работает через корпоративные фаерволы? > Экономия за счет того, что не включают плей и потом забывают посмотреть, а файл полностью загружается, а смотрят ровно столько, сколько была нажата кнопка плей. Замеряли cacti графики до и после использования по трафику почти в 2 раза отличаются. From mdounin at mdounin.ru Mon May 27 12:23:24 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 May 2013 16:23:24 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBINC60LXRiNC40YDQvtCy0LA=?= =?UTF-8?B?0L3QuNC10Lw=?= In-Reply-To: References: Message-ID: <20130527122324.GC72282@mdounin.ru> Hello! On Mon, May 27, 2013 at 02:58:45PM +0400, Nikolay Grebnev wrote: > Добрый день. > > Не получается сделать кеширование для титульных страниц (виртуальных хостов > много). В лог идет все время MISS. При этом в cache директорию что-то > иногда записывается. по какому признаку для меня загадка (иногда как раз те > вещи которые не должны записываться - например страницы отлогинивания, к > счастью в ключе есть$request_uri поэтому это не мешается) . [...] > proxy_cache_valid 200 300s; > proxy_cache_key "$request_method|$host|$request_uri"; > # proxy_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; > proxy_hide_header "Set-Cookie"; > proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и нет из > php когда нет сессии Значине Set-Cookie в директиве proxy_hide_header намекает, что в ответах присутствует заголовок Set-Cookie. Если это так, то nginx не будет такие ответы кешировать - если его явно об этом не попросить с помощью директивы proxy_ignore_headers. http://nginx.org/r/proxy_ignore_headers/ru -- Maxim Dounin http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Mon May 27 12:23:30 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Mon, 27 May 2013 15:23:30 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <651334A6-03A9-4A34-9CF1-8C079809A727@barev.net> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> <651334A6-03A9-4A34-9CF1-8C079809A727@barev.net> Message-ID: <51A35042.2000905@kpi.ua> 27.05.2013 14:53, Eugene Mychlo пишет: > Можно немного поподробнее про задачу парсинга? Фраза не совсем понятна. Ну, вот скажем перелить на свой сервер файл при nginx_mp4_module не составляет особого труда и при этом не потребуется пост обработка, а вот 100500 кусочков HLS - уже проблема. Такая себе защита от клонирования контента на другие сайты, не знаю правда сколько проживет. From nikolaygrebnev at gmail.com Mon May 27 12:40:42 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Mon, 27 May 2013 16:40:42 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBINC60LXRiNC40YDQvtCy0LA=?= =?UTF-8?B?0L3QuNC10Lw=?= In-Reply-To: <20130527122324.GC72282@mdounin.ru> References: <20130527122324.GC72282@mdounin.ru> Message-ID: В базовых ответах кук нет. А если идет кука - то юзер не прилогинен и пусть, соответственно, не кешируется 2013/5/27 Maxim Dounin > Hello! > > On Mon, May 27, 2013 at 02:58:45PM +0400, Nikolay Grebnev wrote: > > > Добрый день. > > > > Не получается сделать кеширование для титульных страниц (виртуальных > хостов > > много). В лог идет все время MISS. При этом в cache директорию что-то > > иногда записывается. по какому признаку для меня загадка (иногда как раз > те > > вещи которые не должны записываться - например страницы отлогинивания, к > > счастью в ключе есть$request_uri поэтому это не мешается) . > > [...] > > > proxy_cache_valid 200 300s; > > proxy_cache_key "$request_method|$host|$request_uri"; > > # proxy_cache_key > > > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; > > proxy_hide_header "Set-Cookie"; > > proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и нет > из > > php когда нет сессии > > Значине Set-Cookie в директиве proxy_hide_header намекает, что в > ответах присутствует заголовок Set-Cookie. Если это так, то nginx > не будет такие ответы кешировать - если его явно об этом не > попросить с помощью директивы proxy_ignore_headers. > > http://nginx.org/r/proxy_ignore_headers/ru > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.vasilishin at kpi.ua Mon May 27 12:44:25 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Mon, 27 May 2013 15:44:25 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <4CFDE39B-AC9E-4B1A-B84D-A3435D717B20@sonru.com> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> <4CFDE39B-AC9E-4B1A-B84D-A3435D717B20@sonru.com> Message-ID: <51A35529.9000905@kpi.ua> 27.05.2013 13:41, Anatoly Mikhailov пишет: > интересно, за счет чего экономия трафика, такой уж большой оверхед у HTTP? Чем замеряли? График прикрепил, трафик упал с 2 Гбит/с полки, до 1.3 Гбит/с в пиках на следующий день после запуска. > HLS - работает через корпоративные фаерволы? > Этим вопросом не задавался. Да и ориентация не на корпоративные фаерволы, а на хом юзера. -------------- next part -------------- A non-text attachment was scrubbed... Name: host-31.png Type: image/png Size: 51023 bytes Desc: not available URL: From nikolaygrebnev at gmail.com Mon May 27 12:45:58 2013 From: nikolaygrebnev at gmail.com (Nikolay Grebnev) Date: Mon, 27 May 2013 16:45:58 +0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtGI0YMg0L/QvtC80L7Rh9GMINGBINC60LXRiNC40YDQvtCy0LA=?= =?UTF-8?B?0L3QuNC10Lw=?= In-Reply-To: References: <20130527122324.GC72282@mdounin.ru> Message-ID: Максим, спасибо!!! По всей видимости, куки там есть! 2013/5/27 Nikolay Grebnev > В базовых ответах кук нет. > А если идет кука - то юзер не прилогинен и пусть, соответственно, не > кешируется > > > 2013/5/27 Maxim Dounin > >> Hello! >> >> On Mon, May 27, 2013 at 02:58:45PM +0400, Nikolay Grebnev wrote: >> >> > Добрый день. >> > >> > Не получается сделать кеширование для титульных страниц (виртуальных >> хостов >> > много). В лог идет все время MISS. При этом в cache директорию что-то >> > иногда записывается. по какому признаку для меня загадка (иногда как >> раз те >> > вещи которые не должны записываться - например страницы отлогинивания, к >> > счастью в ключе есть$request_uri поэтому это не мешается) . >> >> [...] >> >> > proxy_cache_valid 200 300s; >> > proxy_cache_key "$request_method|$host|$request_uri"; >> > # proxy_cache_key >> > >> "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; >> > proxy_hide_header "Set-Cookie"; >> > proxy_ignore_headers "Cache-Control" "Expires"; #собственно их и >> нет из >> > php когда нет сессии >> >> Значине Set-Cookie в директиве proxy_hide_header намекает, что в >> ответах присутствует заголовок Set-Cookie. Если это так, то nginx >> не будет такие ответы кешировать - если его явно об этом не >> попросить с помощью директивы proxy_ignore_headers. >> >> http://nginx.org/r/proxy_ignore_headers/ru >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From myc at barev.net Mon May 27 12:50:32 2013 From: myc at barev.net (Eugene Mychlo) Date: Mon, 27 May 2013 16:50:32 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQtNC10YDQttC60Lgg0L/RgNC4IHByb3h5X2NhY2hlICsgSExT?= In-Reply-To: <51A35042.2000905@kpi.ua> References: <51A3327C.6030407@kpi.ua> <51A33627.8090900@kpi.ua> <651334A6-03A9-4A34-9CF1-8C079809A727@barev.net> <51A35042.2000905@kpi.ua> Message-ID: <802F4966-4F28-4F32-B813-1A6644A39157@barev.net> 27.05.2013, в 16:23, Андрей Василишин написал(а): > 27.05.2013 14:53, Eugene Mychlo пишет: > >> Можно немного поподробнее про задачу парсинга? Фраза не совсем понятна. > > Ну, вот скажем перелить на свой сервер файл при nginx_mp4_module не составляет особого труда и при этом не потребуется пост обработка, а вот 100500 кусочков HLS - уже проблема. Такая себе защита от клонирования контента на другие сайты, не знаю правда сколько проживет. > Абсолютно не проблема собрать из отдельных фрагментов один файл. Достаточно из .m3u8 выдрать номера первого и последнего фрагментов. Далее просто сконкатинировать их. Например: for ((i=1; i <1000; i++)); do curl http://server/stream-nameNum$i.ts ;done > output.ts К тому же vlc/ffmpeg понимает HLS. Соответственно никаких трудностей с сохранении потока не будет. -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From roma at slepchik.com.ua Mon May 27 14:47:20 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 17:47:20 +0300 Subject: $scheme ~* "htt(p|ps)" Message-ID: Доброго времени. Может кто подсказать почему вот такая конструкция не работает? server { server_name my.site.com; listen 80; listen 443; if ($scheme ~* "htt(p|ps)" ) { return 301 https://my.site.com/manager; } Фактически я хочу сделать перенаправление всего на https://my.site.com/manager . С http работает нормально, а вот с https никак, постоянно уходит в циклическую переадресацию. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitriy at lyalyuev.info Mon May 27 14:56:23 2013 From: dmitriy at lyalyuev.info (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JvRj9C70Y7QtdCy?=) Date: Mon, 27 May 2013 17:56:23 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > Доброго времени. Может кто подсказать почему вот такая конструкция не > работает? > server { > server_name my.site.com; > listen 80; > listen 443; > if ($scheme ~* "htt(p|ps)" ) { > return 301 https://my.site.com/manager; > } > Фактически я хочу сделать перенаправление всего на > https://my.site.com/manager . > С http работает нормально, а вот с https никак, постоянно уходит в > циклическую переадресацию. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С уважением, Дмитрий Лялюев тел. +380 (66) 532-29-62 Все контакты для связи на http://lyalyuev.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at slepchik.com.ua Mon May 27 15:00:29 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 18:00:29 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: Это понятно, ну а как тогда сделать правильно переадресанию с https://my.site.com на https://my.site.com/manager 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: > Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > >> Доброго времени. Может кто подсказать почему вот такая конструкция не >> работает? >> server { >> server_name my.site.com; >> listen 80; >> listen 443; >> if ($scheme ~* "htt(p|ps)" ) { >> return 301 https://my.site.com/manager; >> } >> Фактически я хочу сделать перенаправление всего на >> https://my.site.com/manager . >> С http работает нормально, а вот с https никак, постоянно уходит в >> циклическую переадресацию. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > С уважением, > Дмитрий Лялюев > тел. +380 (66) 532-29-62 > Все контакты для связи на http://lyalyuev.info > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С любовью и терпением Роман jabber: roma at slepchik.com.ua skype: zysylcheg icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa.vasilenko at gmail.com Mon May 27 15:04:23 2013 From: aa.vasilenko at gmail.com (Alex Vasilenko) Date: Mon, 27 May 2013 18:04:23 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: On Monday, May 27, 2013 at 18:00 , Рома Сл?пчик wrote: > Это понятно, ну а как тогда сделать правильно переадресанию с https://my.site.com (https://my.site.com/manager) на https://my.site.com/manager > server { server_name my.site.com; listen 80; listen 443; location = / { return 301 https://my.site.com/manager; } } > > 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: > > Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. > > > > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > > > Доброго времени. Может кто подсказать почему вот такая конструкция не работает? > > > server { > > > server_name my.site.com (http://my.site.com); > > > listen 80; > > > listen 443; > > > if ($scheme ~* "htt(p|ps)" ) { > > > return 301 https://my.site.com/manager; > > > } > > > Фактически я хочу сделать перенаправление всего на https://my.site.com/manager . > > > С http работает нормально, а вот с https никак, постоянно уходит в циклическую переадресацию. > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > -- > > С уважением, > > Дмитрий Лялюев > > тел. +380 (66) 532-29-62 (tel:%2B380%20%2866%29%20532-29-62) > > Все контакты для связи на http://lyalyuev.info > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua (mailto:roma at slepchik.com.ua) > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From citrin at citrin.ru Mon May 27 15:06:23 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 27 May 2013 19:06:23 +0400 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: <51A3766F.8030403@citrin.ru> On 05/27/13 19:00, Рома Сл?пчик wrote: > Это понятно, ну а как тогда сделать правильно переадресанию с > https://my.site.com на https://my.site.com/manager > server { server_name my.site.com; listen 80; return 301 https://my.site.com/manager; } server { server_name my.site.com; listen 443; ssl on; location = / { return 301 https://my.site.com/manager; } location /manager { ... } } From sakutylev at mitht.ru Mon May 27 15:07:17 2013 From: sakutylev at mitht.ru (=?KOI8-R?B?69XU2czF1ywg88XSx8XK?=) Date: Mon, 27 May 2013 19:07:17 +0400 Subject: =?UTF-8?B?0LDQstGC0L7RgNC40LfQsNGG0LjRjyDQuCDRgNC10LTQuNGA0LXQutGCINGBINC4?= =?UTF-8?B?0YHQv9C+0LvRjNC30L7QstCw0L3QuNC10LwgYWxsb3cvZGVueSDQuCBzc2w=?= Message-ID: Добрый день подскажите пожалуйста как можно реализовать данный алгоритм в nginx, здесь нечто похожее на satisfy any, только не с паролем а сертификатом. Подробнее. 1) если ip клиента попадает в список allow в конфиге то его отправляет на http://www.example.com. 2) если ip клиента не подпадает под этот список то его редиректит на https://www.example.com где проверка идет по клиентскому сертификату. Спасибо С уважением, *Кутылёв С.А.*, Заместитель начальника управления информатизации и телекоммуникации МИТХТ им М.В. Ломоносова. Тел.: *+7(495) 936-8922* Факс.: *+7(495) 936-8922* Для рабочих писем mail-to: *sakutylev at mitht.ru* Для личных писем mail-to: *sergey at kutylev.com* Моб. тел.: *+7(926) 209-6257* skype: *kibertronix1* -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at slepchik.com.ua Mon May 27 15:11:53 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 18:11:53 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: Такой способ я в первую очередь испытал. Тот же эффект на http все норм на https циклическая переадресация. 27 мая 2013 г., 18:04 пользователь Alex Vasilenko написал: > On Monday, May 27, 2013 at 18:00 , Рома Сл?пчик wrote: > > Это понятно, ну а как тогда сделать правильно переадресанию с > https://my.site.com на > https://my.site.com/manager > > server { > server_name my.site.com; > listen 80; > listen 443; > > location = / { > return 301 https://my.site.com/manager; > } > } > > > > 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: > > Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > > Доброго времени. Может кто подсказать почему вот такая конструкция не > работает? > server { > server_name my.site.com; > listen 80; > listen 443; > if ($scheme ~* "htt(p|ps)" ) { > return 301 https://my.site.com/manager; > } > Фактически я хочу сделать перенаправление всего на > https://my.site.com/manager . > С http работает нормально, а вот с https никак, постоянно уходит в > циклическую переадресацию. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > С уважением, > Дмитрий Лялюев > тел. +380 (66) 532-29-62 > Все контакты для связи на http://lyalyuev.info > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в > жабере) > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С любовью и терпением Роман jabber: roma at slepchik.com.ua skype: zysylcheg icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa.vasilenko at gmail.com Mon May 27 15:13:59 2013 From: aa.vasilenko at gmail.com (Alex Vasilenko) Date: Mon, 27 May 2013 18:13:59 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: <1791A2FE68B1429CAD03D748D5482CF8@gmail.com> On Monday, May 27, 2013 at 18:11 , Рома Сл?пчик wrote: > Такой способ я в первую очередь испытал. Тот же эффект на http все норм на https циклическая переадресация. Тогда рекомендую перепроверить сами методы испытаний. > > > > 27 мая 2013 г., 18:04 пользователь Alex Vasilenko написал: > > On Monday, May 27, 2013 at 18:00 , Рома Сл?пчик wrote: > > > Это понятно, ну а как тогда сделать правильно переадресанию с https://my.site.com (https://my.site.com/manager) на https://my.site.com/manager > > > > > server { > > server_name my.site.com (http://my.site.com); > > listen 80; > > listen 443; > > > > location = / { > > return 301 https://my.site.com/manager; > > } > > } > > > > > > > > 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: > > > > Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. > > > > > > > > > > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > > > > > Доброго времени. Может кто подсказать почему вот такая конструкция не работает? > > > > > server { > > > > > server_name my.site.com (http://my.site.com); > > > > > listen 80; > > > > > listen 443; > > > > > if ($scheme ~* "htt(p|ps)" ) { > > > > > return 301 https://my.site.com/manager; > > > > > } > > > > > Фактически я хочу сделать перенаправление всего на https://my.site.com/manager . > > > > > С http работает нормально, а вот с https никак, постоянно уходит в циклическую переадресацию. > > > > > > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > > > > > -- > > > > С уважением, > > > > Дмитрий Лялюев > > > > тел. +380 (66) 532-29-62 (tel:%2B380%20%2866%29%20532-29-62) > > > > Все контакты для связи на http://lyalyuev.info > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > -- > > > С любовью и терпением Роман > > > jabber: roma at slepchik.com.ua (mailto:roma at slepchik.com.ua) > > > skype: zysylcheg > > > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua (mailto:roma at slepchik.com.ua) > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at onliner.by Mon May 27 15:16:35 2013 From: dan at onliner.by (Daniil) Date: Mon, 27 May 2013 18:16:35 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: server { server_name my.site.com; listen 80; return 301 https://my.site.com$uri$is_args$args; } server { server_name my.site.com; listen 443; location / { ... } } 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > Доброго времени. Может кто подсказать почему вот такая конструкция не > работает? > server { > server_name my.site.com; > listen 80; > listen 443; > if ($scheme ~* "htt(p|ps)" ) { > return 301 https://my.site.com/manager; > } > Фактически я хочу сделать перенаправление всего на > https://my.site.com/manager . > С http работает нормально, а вот с https никак, постоянно уходит в > циклическую переадресацию. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С уважением, Даниил Болсун системный администратор Onliner.by +375 (29 или 44) 77 55 080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at slepchik.com.ua Mon May 27 15:29:14 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 18:29:14 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: <1791A2FE68B1429CAD03D748D5482CF8@gmail.com> References: <1791A2FE68B1429CAD03D748D5482CF8@gmail.com> Message-ID: Их нечего проверять ибо не работает. Меня не интересует редирект с https на https но в таком случае получается циклическая переадресаци. 27 мая 2013 г., 18:13 пользователь Alex Vasilenko написал: > On Monday, May 27, 2013 at 18:11 , Рома Сл?пчик wrote: > > Такой способ я в первую очередь испытал. Тот же эффект на http все норм на > https циклическая переадресация. > > > Тогда рекомендую перепроверить сами методы испытаний. > > > > 27 мая 2013 г., 18:04 пользователь Alex Vasilenko написал: > > On Monday, May 27, 2013 at 18:00 , Рома Сл?пчик wrote: > > Это понятно, ну а как тогда сделать правильно переадресанию с > https://my.site.com на > https://my.site.com/manager > > server { > server_name my.site.com; > listen 80; > listen 443; > > location = / { > return 301 https://my.site.com/manager; > } > } > > > > 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: > > Вероятно потому, что вы переадресовываете с https на https. Вот вам и цикл. > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > > Доброго времени. Может кто подсказать почему вот такая конструкция не > работает? > server { > server_name my.site.com; > listen 80; > listen 443; > if ($scheme ~* "htt(p|ps)" ) { > return 301 https://my.site.com/manager; > } > Фактически я хочу сделать перенаправление всего на > https://my.site.com/manager . > С http работает нормально, а вот с https никак, постоянно уходит в > циклическую переадресацию. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > С уважением, > Дмитрий Лялюев > тел. +380 (66) 532-29-62 > Все контакты для связи на http://lyalyuev.info > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в > жабере) > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в > жабере) > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С любовью и терпением Роман jabber: roma at slepchik.com.ua skype: zysylcheg icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at slepchik.com.ua Mon May 27 15:41:12 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 18:41:12 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: Вы делаете редирект с 80 на 443 я знаю как это делается. Фактически у меня проблема с редиректом https на https так как он не работает так как в теории должен работать. 27 мая 2013 г., 18:16 пользователь Daniil написал: > server { > server_name my.site.com; > listen 80; > > return 301 https://my.site.com$uri$is_args$args; > } > > server { > server_name my.site.com; > listen 443; > > location / { > ... > } > } > > > 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: > >> Доброго времени. Может кто подсказать почему вот такая конструкция не >> работает? >> server { >> server_name my.site.com; >> listen 80; >> listen 443; >> if ($scheme ~* "htt(p|ps)" ) { >> return 301 https://my.site.com/manager; >> } >> Фактически я хочу сделать перенаправление всего на >> https://my.site.com/manager . >> С http работает нормально, а вот с https никак, постоянно уходит в >> циклическую переадресацию. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > С уважением, > Даниил Болсун > системный администратор > Onliner.by > +375 (29 или 44) 77 55 080 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С любовью и терпением Роман jabber: roma at slepchik.com.ua skype: zysylcheg icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at slepchik.com.ua Mon May 27 15:43:36 2013 From: roma at slepchik.com.ua (=?UTF-8?B?0KDQvtC80LAg0KHQu9GU0L/Rh9C40Lo=?=) Date: Mon, 27 May 2013 18:43:36 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: <1791A2FE68B1429CAD03D748D5482CF8@gmail.com> Message-ID: опечатка получилась. Меня как рас интересует редирект с https на https. 27 мая 2013 г., 18:29 пользователь Рома Сл?пчик написал: > Их нечего проверять ибо не работает. > Меня не интересует редирект с https на https но в таком случае получается > циклическая переадресаци. > > > 27 мая 2013 г., 18:13 пользователь Alex Vasilenko написал: > > On Monday, May 27, 2013 at 18:11 , Рома Сл?пчик wrote: >> >> Такой способ я в первую очередь испытал. Тот же эффект на http все норм >> на https циклическая переадресация. >> >> >> Тогда рекомендую перепроверить сами методы испытаний. >> >> >> >> 27 мая 2013 г., 18:04 пользователь Alex Vasilenko > > написал: >> >> On Monday, May 27, 2013 at 18:00 , Рома Сл?пчик wrote: >> >> Это понятно, ну а как тогда сделать правильно переадресанию с >> https://my.site.com на >> https://my.site.com/manager >> >> server { >> server_name my.site.com; >> listen 80; >> listen 443; >> >> location = / { >> return 301 https://my.site.com/manager; >> } >> } >> >> >> >> 27 мая 2013 г., 17:56 пользователь Дмитрий Лялюев написал: >> >> Вероятно потому, что вы переадресовываете с https на https. Вот вам и >> цикл. >> >> >> 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: >> >> Доброго времени. Может кто подсказать почему вот такая конструкция не >> работает? >> server { >> server_name my.site.com; >> listen 80; >> listen 443; >> if ($scheme ~* "htt(p|ps)" ) { >> return 301 https://my.site.com/manager; >> } >> Фактически я хочу сделать перенаправление всего на >> https://my.site.com/manager . >> С http работает нормально, а вот с https никак, постоянно уходит в >> циклическую переадресацию. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> >> -- >> С уважением, >> Дмитрий Лялюев >> тел. +380 (66) 532-29-62 >> Все контакты для связи на http://lyalyuev.info >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> >> -- >> С любовью и терпением Роман >> jabber: roma at slepchik.com.ua >> skype: zysylcheg >> icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в >> жабере) >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> >> -- >> С любовью и терпением Роман >> jabber: roma at slepchik.com.ua >> skype: zysylcheg >> icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в >> жабере) >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в > жабере) > -- С любовью и терпением Роман jabber: roma at slepchik.com.ua skype: zysylcheg icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в жабере) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at onliner.by Mon May 27 16:04:13 2013 From: dan at onliner.by (Daniil) Date: Mon, 27 May 2013 19:04:13 +0300 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: Message-ID: 27 мая 2013 г., 18:41 пользователь Рома Сл?пчик написал: > > Вы делаете редирект с 80 на 443 я знаю как это делается. Фактически у меня > проблема с редиректом https на https так как он не работает так как в > теории должен работать. > > > 27 мая 2013 г., 18:16 пользователь Daniil написал: > > server { >> server_name my.site.com; >> listen 80; >> >> return 301 https://my.site.com$uri$is_args$args; >> } >> >> server { >> server_name my.site.com; >> listen 443; >> >> location / { >> ... >> } >> } >> >> >> 27 мая 2013 г., 17:47 пользователь Рома Сл?пчик написал: >> >>> Доброго времени. Может кто подсказать почему вот такая конструкция не >>> работает? >>> server { >>> server_name my.site.com; >>> listen 80; >>> listen 443; >>> if ($scheme ~* "htt(p|ps)" ) { >>> return 301 https://my.site.com/manager; >>> } >>> Фактически я хочу сделать перенаправление всего на >>> https://my.site.com/manager . >>> С http работает нормально, а вот с https никак, постоянно уходит в >>> циклическую переадресацию. >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> >> -- >> С уважением, >> Даниил Болсун >> системный администратор >> Onliner.by >> +375 (29 или 44) 77 55 080 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > С любовью и терпением Роман > jabber: roma at slepchik.com.ua > skype: zysylcheg > icq: 270332886 (не часто пользую богомерские протоколы, так что ищите в > жабере) > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > Простите, не до конца понял поставленную задачу. В случае, если вам нужно все запросы с http и с https перенаправлять на https://my.site.com/manager, то можно сделать так: server { server_name my.site.com; listen 80; return 301 https://my.site.com/manager; } server { server_name my.site.com; listen 443; location / { return 301 /manager; } location /manager { ... } } -- С уважением, Даниил Болсун системный администратор Onliner.by +375 (29 или 44) 77 55 080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon May 27 16:04:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 May 2013 20:04:31 +0400 Subject: $scheme ~* "htt(p|ps)" In-Reply-To: References: <1791A2FE68B1429CAD03D748D5482CF8@gmail.com> Message-ID: <20130527160431.GK72282@mdounin.ru> Hello! On Mon, May 27, 2013 at 06:43:36PM +0300, Рома Сл?пчик wrote: > опечатка получилась. Меня как рас интересует редирект с https на https. Помимо опечатки, у вас ещё получилось непонимание того, что вам предложили. Посмотрите на пример внимательно ещё раз - может быть, озарение таки случится. Если не случится - посмотрите на пример конфигурации, который привёл Антон Южанинов. Там предложено приблизительно то же самое, но с большим количеством подробностей. Ну а если и это не поможет, то следует действовать уже по классической формуле - "Если ничего не помогает - прочтите, наконец, документацию." Документацию берут тут: http://nginx.org/r/location/ru В частности, обратите внимание на модификатор "=". Хотя он тут, строго говоря, не нужен. Достаточно, чтобы обработка того, что не нужно перенаправлять, была в другом location'е. [...] -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon May 27 16:08:48 2013 From: nginx-forum at nginx.us (azzis) Date: Mon, 27 May 2013 12:08:48 -0400 Subject: =?UTF-8?B?0JTQstCwINGA0YPRgtCwINCyINC/0YDQtdC00LXQu9Cw0YUg0L7QtNC90L7Qs9C+?= =?UTF-8?B?INGB0LXRgNCy0LXRgNCw?= Message-ID: <23b7be79b2917eb4f51dcca64404abe3.NginxMailingListRussian@forum.nginx.org> Прошу помощи, бьюсь третий день... По факту есть два сайта на на Джумле на одном доменном имени: site1 и site1/eng. Лежат в папках /var/www/site1 и /var/www/site2 соответсвенно. Для site1 написана конфигурация которая замечательно работает: location / { root /var/www/site1/www; index index.php index.html; try_files $uri $uri/ @rewrite; } location @rewrite { #root /var/www/site1/www; rewrite ^/(.*)$ /index.php?q=$1; } location ~ \.php$ { root /var/www/site1/www; try_files $uri $uri/ @rewrite; fastcgi_pass unix:/var/run/php-fpm/www.conf; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/index.php; include fastcgi_params; } location ~ ^/(images/|media/|sud/|templates/|robots\.txt$|administrator/help/|administrator/manifests/|administrator/templates/) { root /var/www/maxi-group/www; } Не было никаких проблем если бы доменные имена были бы разные. Но все осложняется тем что доменное имя одно и фактически site2 - это английская версия site1. Все это прекрасно работало в связке с apache, но теперь от него отказываемся и нужно настроить без него. Никак не могу одолеть конфигурацию для второго сайта. Поможите люди добрые! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239597,239597#msg-239597 From nginx-forum at nginx.us Mon May 27 16:48:38 2013 From: nginx-forum at nginx.us (Mitry Matyushkov) Date: Mon, 27 May 2013 12:48:38 -0400 Subject: =?UTF-8?B?dXdzZ2kgcGFzcyDQvdC1INGA0LDRgdC60YDRi9Cy0LDQtdGCINC/0LXRgNC10Lw=?= =?UTF-8?B?0LXQvdC90YvQtT8=?= Message-ID: <3d10657b5796d5586ee616e53a953069.NginxMailingListRussian@forum.nginx.org> Привет всем. Перевожу проект на uwsgi, столкнулся с фичей: upstream up { server 127.0.0.1:12345; } proxy_pass http://${var}up; работает, но при замене на: uwsgi_pass ${var}up; получаю: nginx -t nginx: [emerg] directive "uwsgi_pass" is not terminated by ";" in /etc/nginx/includes/proxy.conf:9 Как жить дальше? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239598,239598#msg-239598 From onokonem at gmail.com Mon May 27 16:49:36 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 27 May 2013 20:49:36 +0400 Subject: =?UTF-8?B?UmU6INCU0LLQsCDRgNGD0YLQsCDQsiDQv9GA0LXQtNC10LvQsNGFINC+0LTQvdC+?= =?UTF-8?B?0LPQviDRgdC10YDQstC10YDQsA==?= In-Reply-To: <23b7be79b2917eb4f51dcca64404abe3.NginxMailingListRussian@forum.nginx.org> References: <23b7be79b2917eb4f51dcca64404abe3.NginxMailingListRussian@forum.nginx.org> Message-ID: 2013/5/27 azzis : > Не было никаких проблем если бы доменные имена были бы разные. Но все > осложняется тем что доменное имя одно и фактически site2 - это английская > версия site1. правильно я понимаю, что различать, кому что отдавать, вы хотите с помощью Accept-Language заголовка? тогда if и именованные локейшены вам в помощь. From mdounin at mdounin.ru Mon May 27 17:10:44 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 May 2013 21:10:44 +0400 Subject: =?UTF-8?B?UmU6IHV3c2dpIHBhc3Mg0L3QtSDRgNCw0YHQutGA0YvQstCw0LXRgiDQv9C10YA=?= =?UTF-8?B?0LXQvNC10L3QvdGL0LU/?= In-Reply-To: <3d10657b5796d5586ee616e53a953069.NginxMailingListRussian@forum.nginx.org> References: <3d10657b5796d5586ee616e53a953069.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130527171044.GM72282@mdounin.ru> Hello! On Mon, May 27, 2013 at 12:48:38PM -0400, Mitry Matyushkov wrote: > Привет всем. > > Перевожу проект на uwsgi, столкнулся с фичей: > > upstream up { > server 127.0.0.1:12345; > } > > proxy_pass http://${var}up; > > работает, но при замене на: > > uwsgi_pass ${var}up; > > получаю: > nginx -t > nginx: [emerg] directive "uwsgi_pass" is not terminated by ";" in > /etc/nginx/includes/proxy.conf:9 > > Как жить дальше? uwsgi_pass "${var}up"; -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon May 27 17:21:26 2013 From: nginx-forum at nginx.us (Mitry Matyushkov) Date: Mon, 27 May 2013 13:21:26 -0400 Subject: =?UTF-8?B?UmU6IHV3c2dpIHBhc3Mg0L3QtSDRgNCw0YHQutGA0YvQstCw0LXRgiDQv9C10YA=?= =?UTF-8?B?0LXQvNC10L3QvdGL0LU/?= In-Reply-To: <20130527171044.GM72282@mdounin.ru> References: <20130527171044.GM72282@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Mon, May 27, 2013 at 12:48:38PM -0400, Mitry Matyushkov wrote: > > > Привет всем. > > > > Перевожу проект на uwsgi, столкнулся с фичей: > > > > upstream up { > > server 127.0.0.1:12345; > > } > > > > proxy_pass http://${var}up; > > > > работает, но при замене на: > > > > uwsgi_pass ${var}up; > > > > получаю: > > nginx -t > > nginx: [emerg] directive "uwsgi_pass" is not terminated by ";" in > > /etc/nginx/includes/proxy.conf:9 > > > > Как жить дальше? > > uwsgi_pass "${var}up"; Спасибо, помогло. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239602,239603#msg-239603 From denis at webmaster.spb.ru Tue May 28 05:19:08 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 28 May 2013 09:19:08 +0400 Subject: =?UTF-8?B?0YPQstC10LTQvtC80LvQtdC90LjQtSDQviDQv9C10YDQtdGF0L7QtNC1INC90LAg?= =?UTF-8?B?0YHQu9C10LnQsg==?= Message-ID: <51A43E4C.4070400@webmaster.spb.ru> Как узнать_на мастере_, что запрос(ы) начали идти на сервера, помеченные как backup? На резерве понятно, открываем аксес логи (нгинха/апача) и смотрим на появление новых записей... Но надо именно с мастера. From vlisenko.3s at gmail.com Tue May 28 06:03:53 2013 From: vlisenko.3s at gmail.com (Vitaliy Lysenko) Date: Tue, 28 May 2013 13:03:53 +0700 Subject: =?UTF-8?B?UmU6INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LTQtSA=?= =?UTF-8?B?0L3QsCDRgdC70LXQudCy?= In-Reply-To: <51A43E4C.4070400@webmaster.spb.ru> References: <51A43E4C.4070400@webmaster.spb.ru> Message-ID: на мастере в логе $upstream_addr разве не будет == айпишнику бекапного бекенда? 28 мая 2013 г., 12:19 пользователь denis написал: > Как узнать_на мастере_, что запрос(ы) начали идти на сервера, помеченные > как backup? На резерве понятно, открываем аксес логи (нгинха/апача) и > смотрим на появление новых записей... Но надо именно с мастера. > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Tue May 28 06:07:27 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 28 May 2013 10:07:27 +0400 Subject: =?UTF-8?B?UmU6INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LTQtSA=?= =?UTF-8?B?0L3QsCDRgdC70LXQudCy?= In-Reply-To: <51A43E4C.4070400@webmaster.spb.ru> References: <51A43E4C.4070400@webmaster.spb.ru> Message-ID: <743618290.20130528100727@softsearch.ru> Здравствуйте, denis. > Как узнать_на мастере_, что запрос(ы) начали идти на сервера, > помеченные как backup? На резерве понятно, открываем аксес логи > (нгинха/апача) и смотрим на появление новых записей... Но надо > именно с мастера. Не знаю, что такое мастер в nginx-е. Но можно писать на фронтэнде $upstream_addr и $upstream_status в лог и по ним смотреть, куда делались запросы и какие были ответы. -- С уважением, Михаил mailto:postmaster at softsearch.ru From vlisenko.3s at gmail.com Tue May 28 06:11:38 2013 From: vlisenko.3s at gmail.com (Vitaliy Lysenko) Date: Tue, 28 May 2013 13:11:38 +0700 Subject: =?UTF-8?B?UmU6INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LTQtSA=?= =?UTF-8?B?0L3QsCDRgdC70LXQudCy?= In-Reply-To: <743618290.20130528100727@softsearch.ru> References: <51A43E4C.4070400@webmaster.spb.ru> <743618290.20130528100727@softsearch.ru> Message-ID: я полагаю, что мастером Денис назвал фронтэнда ) 28 мая 2013 г., 13:07 пользователь Михаил Монашёв написал: > Здравствуйте, denis. > > > Как узнать_на мастере_, что запрос(ы) начали идти на сервера, > > помеченные как backup? На резерве понятно, открываем аксес логи > > (нгинха/апача) и смотрим на появление новых записей... Но надо > > именно с мастера. > > Не знаю, что такое мастер в nginx-е. Но можно писать на фронтэнде > $upstream_addr и $upstream_status в лог и по ним смотреть, куда > делались запросы и какие были ответы. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Tue May 28 06:33:25 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 28 May 2013 10:33:25 +0400 Subject: =?UTF-8?B?UmVbMl06INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LQ=?= =?UTF-8?B?0LUg0L3QsCDRgdC70LXQudCy?= In-Reply-To: References: <51A43E4C.4070400@webmaster.spb.ru> <743618290.20130528100727@softsearch.ru> Message-ID: <893665416.20130528103325@softsearch.ru> Здравствуйте, Vitaliy. > я полагаю, что мастером Денис назвал фронтэнда ) Или единственный сервер в апстриме, который не помечен как backup. Подозреваю, что Денис пишет на php. :-)))) -- С уважением, Михаил mailto:postmaster at softsearch.ru From ilvin at mail.ru Tue May 28 07:48:59 2013 From: ilvin at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 28 May 2013 11:48:59 +0400 Subject: =?UTF-8?B?UmVbM106INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LQ=?= =?UTF-8?B?0LUg0L3QsCDRgdC70LXQudCy?= In-Reply-To: <893665416.20130528103325@softsearch.ru> References: <51A43E4C.4070400@webmaster.spb.ru> <893665416.20130528103325@softsearch.ru> Message-ID: <1369727339.281342422@f151.mail.ru> И не подозревает, что здесь суровые парни пишут на конфиге nginx :) С почтением,   Илья Винокуров. Вторник, 28 мая 2013, 10:33 +04:00 от Михаил Монашёв : >Здравствуйте, Vitaliy. > >> я полагаю, что мастером Денис назвал фронтэнда ) > >Или единственный сервер в апстриме, который не помечен как backup. > >Подозреваю, что Денис пишет на php. :-)))) > >-- >С уважением, > Михаил mailto: postmaster at softsearch.ru > >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Tue May 28 08:57:32 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 28 May 2013 09:57:32 +0100 Subject: =?UTF-8?B?UzMgcHJlLXNpZ25lZCBwcml2YXRlIFVSTCDQsNC70LPQvtGA0LjRgtC8INC90LAg?= =?UTF-8?B?Tmdpbng=?= Message-ID: <78DD1705-C605-4CD3-A089-CA70E89D4EB6@sonru.com> AWS S3 предлагает возможность создавать short-lived URL для файлов с приватным доступом, алгоритм реализован в AWS SDK для разных языков (Ruby, ObjectiveC, .NET, Java, Android, PHP). На AWS SDK для Ruby это выглядит так: AWS::S3.new.buckets[s3_bucket].objects[path].url_for(:read, :expires => 7200).request_uri[1..-1] Есть ли возможность имплементировать алгоритм в Nginx, или уже есть такой модуль? Анатолий From anatoly at sonru.com Tue May 28 09:43:34 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 28 May 2013 10:43:34 +0100 Subject: =?UTF-8?B?UmU6IFMzIHByZS1zaWduZWQgcHJpdmF0ZSBVUkwg0LDQu9Cz0L7RgNC40YLQvCA=?= =?UTF-8?B?0L3QsCBOZ2lueA==?= In-Reply-To: <78DD1705-C605-4CD3-A089-CA70E89D4EB6@sonru.com> References: <78DD1705-C605-4CD3-A089-CA70E89D4EB6@sonru.com> Message-ID: <1D8BD53D-69A9-4046-A82F-936CA3AAF782@sonru.com> On May 28, 2013, at 9:57 AM, Anatoly Mikhailov wrote: > AWS S3 предлагает возможность создавать short-lived URL для файлов с приватным доступом, > алгоритм реализован в AWS SDK для разных языков (Ruby, ObjectiveC, .NET, Java, Android, PHP). > > На AWS SDK для Ruby это выглядит так: AWS::S3.new.buckets[s3_bucket].objects[path].url_for(:read, :expires => 7200).request_uri[1..-1] > > Есть ли возможность имплементировать алгоритм в Nginx, или уже есть такой модуль? > Если есть вопросы о целесообразности, то здесь смысл один - проксировать приватные файлы с S3 без участия бэкэнда. Про secure_link_md5 знаю хорошо и он используется в продакшне для своих целей. > Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From aa.vasilenko at gmail.com Tue May 28 09:47:00 2013 From: aa.vasilenko at gmail.com (Alex Vasilenko) Date: Tue, 28 May 2013 12:47:00 +0300 Subject: =?UTF-8?B?UmU6IFMzIHByZS1zaWduZWQgcHJpdmF0ZSBVUkwg0LDQu9Cz0L7RgNC40YLQvCA=?= =?UTF-8?B?0L3QsCBOZ2lueA==?= In-Reply-To: <1D8BD53D-69A9-4046-A82F-936CA3AAF782@sonru.com> References: <78DD1705-C605-4CD3-A089-CA70E89D4EB6@sonru.com> <1D8BD53D-69A9-4046-A82F-936CA3AAF782@sonru.com> Message-ID: <144B8DD1A0264A49A87E8D74F58DCB3F@gmail.com> On Tuesday, May 28, 2013 at 12:43 , Anatoly Mikhailov wrote: > > On May 28, 2013, at 9:57 AM, Anatoly Mikhailov wrote: > > > AWS S3 предлагает возможность создавать short-lived URL для файлов с приватным доступом, > > алгоритм реализован в AWS SDK для разных языков (Ruby, ObjectiveC, .NET, Java, Android, PHP). > > > > На AWS SDK для Ruby это выглядит так: AWS::S3.new.buckets[s3_bucket].objects[path].url_for(:read, :expires => 7200).request_uri[1..-1] > > > > Есть ли возможность имплементировать алгоритм в Nginx, или уже есть такой модуль? > > Если есть вопросы о целесообразности, то здесь смысл один - проксировать приватные файлы с S3 без участия бэкэнда. > Про secure_link_md5 знаю хорошо и он используется в продакшне для своих целей. > > Пробовали XSendFile? http://wiki.nginx.org/XSendfile Или хотите совсем-совсем без бекенда? > > > Анатолий > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org (mailto:nginx-ru at nginx.org) > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Tue May 28 09:57:22 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 28 May 2013 10:57:22 +0100 Subject: =?UTF-8?B?UmU6IFMzIHByZS1zaWduZWQgcHJpdmF0ZSBVUkwg0LDQu9Cz0L7RgNC40YLQvCA=?= =?UTF-8?B?0L3QsCBOZ2lueA==?= In-Reply-To: <144B8DD1A0264A49A87E8D74F58DCB3F@gmail.com> References: <78DD1705-C605-4CD3-A089-CA70E89D4EB6@sonru.com> <1D8BD53D-69A9-4046-A82F-936CA3AAF782@sonru.com> <144B8DD1A0264A49A87E8D74F58DCB3F@gmail.com> Message-ID: On May 28, 2013, at 10:47 AM, Alex Vasilenko wrote: > On Tuesday, May 28, 2013 at 12:43 , Anatoly Mikhailov wrote: >> >> On May 28, 2013, at 9:57 AM, Anatoly Mikhailov wrote: >> >>> AWS S3 предлагает возможность создавать short-lived URL для файлов с приватным доступом, >>> алгоритм реализован в AWS SDK для разных языков (Ruby, ObjectiveC, .NET, Java, Android, PHP). >>> >>> На AWS SDK для Ruby это выглядит так: AWS::S3.new.buckets[s3_bucket].objects[path].url_for(:read, :expires => 7200).request_uri[1..-1] >>> >>> Есть ли возможность имплементировать алгоритм в Nginx, или уже есть такой модуль? >> >> Если есть вопросы о целесообразности, то здесь смысл один - проксировать приватные файлы с S3 без участия бэкэнда. >> Про secure_link_md5 знаю хорошо и он используется в продакшне для своих целей. > > Пробовали XSendFile? http://wiki.nginx.org/XSendfile Или хотите совсем-совсем без бекенда? Пробовал, но задача совершенно другая >> >>> Анатолий >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Tue May 28 22:16:06 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 28 May 2013 23:16:06 +0100 Subject: =?UTF-8?B?cGVybWFuZW50IHJlZGlyZWN0INC00LvRjyDQstGB0LXRhSDQt9Cw0L/RgNC+0YE=?= =?UTF-8?B?0L7QsiDQutGA0L7QvNC1INC+0LTQvdC+0LPQvg==?= Message-ID: <77CE2346-90A3-44E3-8347-3F77F7B0579B@sonru.com> Есть следующий конфиг для перманентного редиректа HTTP на HTTPS: server { listen 80; server_name admin.sonru.com; rewrite ^(.*) https://$host$1 permanent; } Задача в том, чтобы теперь перенаправлять http->https весь трафик кроме запроса на location = /health-check. Как это лучше всего сделать? Анатолий From anatoly at sonru.com Tue May 28 22:23:46 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Tue, 28 May 2013 23:23:46 +0100 Subject: =?UTF-8?B?UmU6IHBlcm1hbmVudCByZWRpcmVjdCDQtNC70Y8g0LLRgdC10YUg0LfQsNC/0YA=?= =?UTF-8?B?0L7RgdC+0LIg0LrRgNC+0LzQtSDQvtC00L3QvtCz0L4=?= In-Reply-To: <77CE2346-90A3-44E3-8347-3F77F7B0579B@sonru.com> References: <77CE2346-90A3-44E3-8347-3F77F7B0579B@sonru.com> Message-ID: <8E73911A-E745-490D-8ABA-7ACF58344CEC@sonru.com> On May 28, 2013, at 11:16 PM, Anatoly Mikhailov wrote: > Есть следующий конфиг для перманентного редиректа HTTP на HTTPS: > > server { > listen 80; > server_name admin.sonru.com; > rewrite ^(.*) https://$host$1 permanent; > } > > Задача в том, чтобы теперь перенаправлять http->https весь трафик кроме > запроса на location = /health-check. Как это лучше всего сделать? > задача то простая, но ее обычно так решают? if ($request_uri != '/health-check') { rewrite ^(.*) https://$host$1 permanent; } location = /health-check { return 200; } > Анатолий > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From tetsio.nainn at gmail.com Tue May 28 22:35:14 2013 From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=) Date: Wed, 29 May 2013 08:35:14 +1000 Subject: =?UTF-8?B?UmU6IHBlcm1hbmVudCByZWRpcmVjdCDQtNC70Y8g0LLRgdC10YUg0LfQsNC/0YA=?= =?UTF-8?B?0L7RgdC+0LIg0LrRgNC+0LzQtSDQvtC00L3QvtCz0L4=?= In-Reply-To: <8E73911A-E745-490D-8ABA-7ACF58344CEC@sonru.com> References: <77CE2346-90A3-44E3-8347-3F77F7B0579B@sonru.com> <8E73911A-E745-490D-8ABA-7ACF58344CEC@sonru.com> Message-ID: location / { rewrite ^(.*) https://$host$1 permanent; } location = /health-check { return 200; } 29 мая 2013 г., 8:23 пользователь Anatoly Mikhailov написал: > > On May 28, 2013, at 11:16 PM, Anatoly Mikhailov wrote: > > > Есть следующий конфиг для перманентного редиректа HTTP на HTTPS: > > > > server { > > listen 80; > > server_name admin.sonru.com; > > rewrite ^(.*) https://$host$1 permanent; > > } > > > > Задача в том, чтобы теперь перенаправлять http->https весь трафик кроме > > запроса на location = /health-check. Как это лучше всего сделать? > > > > задача то простая, но ее обычно так решают? > > if ($request_uri != '/health-check') { > rewrite ^(.*) https://$host$1 permanent; > } > > location = /health-check { > return 200; > } > > > Анатолий > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Tue May 28 22:35:46 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 29 May 2013 02:35:46 +0400 Subject: =?UTF-8?B?UmU6IHBlcm1hbmVudCByZWRpcmVjdCAg0LTQu9GPINCy0YHQtdGFINC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0LrRgNC+0LzQtSDQvtC00L3QvtCz0L4=?= In-Reply-To: <8E73911A-E745-490D-8ABA-7ACF58344CEC@sonru.com> References: <77CE2346-90A3-44E3-8347-3F77F7B0579B@sonru.com> <8E73911A-E745-490D-8ABA-7ACF58344CEC@sonru.com> Message-ID: <201305290235.47014.vbart@nginx.com> On Wednesday 29 May 2013 02:23:46 Anatoly Mikhailov wrote: > On May 28, 2013, at 11:16 PM, Anatoly Mikhailov wrote: > > Есть следующий конфиг для перманентного редиректа HTTP на HTTPS: > > > > server { > > > > listen 80; > > server_name admin.sonru.com; > > rewrite ^(.*) https://$host$1 permanent; > > > > } > > > > Задача в том, чтобы теперь перенаправлять http->https весь трафик кроме > > запроса на location = /health-check. Как это лучше всего сделать? > > задача то простая, но ее обычно так решают? > Нет. > if ($request_uri != '/health-check') { > rewrite ^(.*) https://$host$1 permanent; > } > > location = /health-check { > return 200; > } > location / { return 301 https://admin.sonru.com$request_uri; } location = /health-check { ... } -- Валентин Бартенев http://nginx.org/en/donation.html From denis at webmaster.spb.ru Tue May 28 23:39:36 2013 From: denis at webmaster.spb.ru (denis) Date: Wed, 29 May 2013 03:39:36 +0400 Subject: =?UTF-8?B?UmU6INGD0LLQtdC00L7QvNC70LXQvdC40LUg0L4g0L/QtdGA0LXRhdC+0LTQtSA=?= =?UTF-8?B?0L3QsCDRgdC70LXQudCy?= In-Reply-To: <893665416.20130528103325@softsearch.ru> References: <51A43E4C.4070400@webmaster.spb.ru> <743618290.20130528100727@softsearch.ru> <893665416.20130528103325@softsearch.ru> Message-ID: <51A54038.1060802@webmaster.spb.ru> 28.05.2013 10:33, Михаил Монашёв пишет: > Или единственный сервер в апстриме, который не помечен как backup. Да. Сервер, на который приходят сами запросы. > Подозреваю, что Денис пишет на php. :-)))) сайты на перле, а конфиги в конфигах ) Нужно же как-то отслеживать текущее состояние работы, штатно это если и есть - запрятано сильно. Вот $upstream_status посмотрим, может то что требовалось... From nginx-forum at nginx.us Wed May 29 00:37:17 2013 From: nginx-forum at nginx.us (aageyev) Date: Tue, 28 May 2013 20:37:17 -0400 Subject: =?UTF-8?B?0KPQstC10LvQuNGH0LXQvdC40LUgbGF0ZW5jeSDQv9GA0Lgg0YHRgtCw0YDRgtC1?= =?UTF-8?B?IG5naW54?= Message-ID: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Столкнулся с достаточно загадочной для меня ситуацией. Ping сервера с выключенным nginx icmp_req=9 ttl=61 time=0.652 ms Через 3 минуты после старта nginx icmp_req=129 ttl=61 time=229 ms Сервер используется под хостинг wordpress OS: Ubuntu 12.10 nginx.conf user www-data; worker_processes 4; worker_rlimit_nofile 250000; pid /var/run/nginx.pid; events { worker_connections 4096; multi_accept on; use epoll; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server_names_hash_bucket_size 512; reset_timedout_connection on; resolver 127.0.0.1; resolver_timeout 10s; open_file_cache max=100000 inactive=40s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on; access_log off; server_tokens off; sendfile off; tcp_nopush off; keepalive_timeout 10; tcp_nodelay off; send_timeout 2; gzip off; client_header_buffer_size 4k; large_client_header_buffers 8 8k; output_buffers 32 512k; sendfile_max_chunk 128k; postpone_output 1460; log_format main '$remote_addr - $remote_user [$time_local] $domain ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Server-conf server { listen 80 default_server; server_name ~^(www\.)?(?.+)$; access_log /var/log/nginx/wp-access.log csv buffer=1m; error_log /var/log/nginx/wp-error.log; root /var/www/$domain; index index.php; location ~ \.(css|js|htc)$ { access_log off; log_not_found off; } location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ { } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } location = /apple-touch-icon.png { access_log off; log_not_found off; } location = /apple-touch-icon-precomposed.png { access_log off; log_not_found off; } location = /wp-content { access_log off; expires max; } # Common deny or internal locations, to help prevent access to areas of # the site that should not be public location ~* wp-admin/includes { deny all; } location ~* wp-includes/theme-compat/ { deny all; } location ~* wp-includes/js/tinymce/langs/.*\.php { deny all; } location /wp-includes/ { internal; } location ~* wp-config.php { deny all; } #location ~* ^/wp-content/uploads/.*.(html|htm|shtml|php)$ { # types { } # default_type text/plain; #} location ~ /\. { deny all; access_log off; log_not_found off; } location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { fastcgi_pass php5-fpm-sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; proxy_ignore_client_abort on; proxy_connect_timeout 120; proxy_read_timeout 60; proxy_send_timeout 60; proxy_buffers 8 32k; proxy_buffer_size 64k; include /etc/nginx/fastcgi_params; } } В логах nginx и syslog ничего аномального нет. Подскажите, пожалуйста, с чем это может быть связанно и в какую сторону копать? Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239645,239645#msg-239645 From mdounin at mdounin.ru Wed May 29 02:49:38 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 29 May 2013 06:49:38 +0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C10L3QuNC1IGxhdGVuY3kg0L/RgNC4INGB0YLQsNGA?= =?UTF-8?B?0YLQtSBuZ2lueA==?= In-Reply-To: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> References: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20130529024938.GV72282@mdounin.ru> Hello! On Tue, May 28, 2013 at 08:37:17PM -0400, aageyev wrote: > Здравствуйте. > > Столкнулся с достаточно загадочной для меня ситуацией. > > Ping сервера с выключенным nginx > > icmp_req=9 ttl=61 time=0.652 ms > > Через 3 минуты после старта nginx > > icmp_req=129 ttl=61 time=229 ms [...] > В логах nginx и syslog ничего аномального нет. > > Подскажите, пожалуйста, с чем это может быть связанно и в какую сторону > копать? Наиболее банальный вариант - просто кончается канал. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed May 29 08:11:24 2013 From: nginx-forum at nginx.us (skeletor) Date: Wed, 29 May 2013 04:11:24 -0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C10L3QuNC1IGxhdGVuY3kg0L/RgNC4INGB0YLQsNGA?= =?UTF-8?B?0YLQtSBuZ2lueA==?= In-Reply-To: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> References: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> Message-ID: netstat/trafshow/nettop/iftop смотрите в момент запуска. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239645,239649#msg-239649 From dan at onliner.by Wed May 29 08:18:58 2013 From: dan at onliner.by (Daniil) Date: Wed, 29 May 2013 11:18:58 +0300 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C10L3QuNC1IGxhdGVuY3kg0L/RgNC4INGB0YLQsNGA?= =?UTF-8?B?0YLQtSBuZ2lueA==?= In-Reply-To: References: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> Message-ID: Посмотрите также /var/log/kern.log на наличие "possible syn flooding" 29 мая 2013 г., 11:11 пользователь skeletor написал: > netstat/trafshow/nettop/iftop смотрите в момент запуска. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239645,239649#msg-239649 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С уважением, Даниил Болсун системный администратор Onliner.by +375 (29 или 44) 77 55 080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey at kopeyko.ru Wed May 29 09:14:29 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 29 May 2013 13:14:29 +0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C10L3QuNC1IGxhdGVuY3kg0L/RgNC4INGB0YLQsNGA?= =?UTF-8?B?0YLQtSBuZ2lueA==?= In-Reply-To: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> References: <6e41000d466dee5af49e4a1b89891d9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <51A5C6F5.4090609@kopeyko.ru> 29.05.2013 04:37, aageyev пишет: > Здравствуйте. Добрый день! > Столкнулся с достаточно загадочной для меня ситуацией. > > Ping сервера с выключенным nginx > icmp_req=9 ttl=61 time=0.652 ms > > Через 3 минуты после старта nginx > icmp_req=129 ttl=61 time=229 ms А выключение nginx - приводит к возвращению RTT к прежним значениям? Или не пробовали? Если таки приводит - Максим прав, это таки забивание канала. Весьма похоже, что трафик на\от ваш сервер шейпится провайдером\хостером. > -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Wed May 29 09:18:51 2013 From: nginx-forum at nginx.us (aageyev) Date: Wed, 29 May 2013 05:18:51 -0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C10L3QuNC1IGxhdGVuY3kg0L/RgNC4INGB0YLQsNGA?= =?UTF-8?B?0YLQtSBuZ2lueA==?= In-Reply-To: <51A5C6F5.4090609@kopeyko.ru> References: <51A5C6F5.4090609@kopeyko.ru> Message-ID: <786ecf62e0f5892dae806e4a7af4829d.NginxMailingListRussian@forum.nginx.org> Здравствуйте Андрей Выключение nginx приводит все в исходное состояние с нормальным RTT -- Regards, Andrey Ageyev Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239645,239652#msg-239652 From i at trushkin.ru Thu May 30 06:13:16 2013 From: i at trushkin.ru (=?UTF-8?B?0K7RgNC40Lkg0KLRgNGD0YjQutC40L0=?=) Date: Thu, 30 May 2013 10:13:16 +0400 Subject: =?UTF-8?B?RndkOiBmY2dpINC/0L7QtNC30LDQv9GA0L7RgdGL?= In-Reply-To: References: Message-ID: Всем доброго дня! Не могу побороть проблему, требуется подсказка. Запустил связку nginx+fastcgi-parser3. Всё вроде работает, но столкнулся с такой проблемой: Если сделать load страницы по http/https на тестовый скрипт, который в свою очередь попробует загрузить страницу с клиента, последующие запросы подвисают и как бы ждут пока завершится первый. Получаем 504. В логах только: 2013/05/30 10:02:15 [info] 91833#0: *80397 kevent() reported that client 213.80.130.123 closed keepalive connection Если с клиента делаем load страницы, без последующих load-oв, то всё нормально. nginx version: nginx/1.2.9 ОС: FreeBSD 8.2 Конфиг: server { error_log /var/log/debug.log debug; listen 80; server_name ourhost.test; set $rf "ourhost"; set $acc "outhost"; charset utf-8; source_charset utf-8; root /htdocs/$rf; location ~ / { index index.p3 index.html; location ~ \.p3 { try_files $uri =404; fastcgi_pass 127.0.0.1:8003; fastcgi_index index.p3; fastcgi_param SCRIPT_NAME $request_uri; fastcgi_param SCRIPT_FILENAME /cgi-bin/parser.cgi; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param PATH_TRANSLATED /htdocs/$rf$fastcgi_script_name; fastcgi_param CGI_PARSER_CONFIG /parser3/auto.p; fastcgi_param CGI_PARSER_LOG /var/log/httpd/error.log; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; } } } -- С уважением, Юрий Трушкин. -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu May 30 06:19:37 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 30 May 2013 10:19:37 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: > Если сделать load страницы по http/https на тестовый скрипт, который в свою > очередь попробует загрузить страницу с клиента, последующие запросы > подвисают и как бы ждут пока завершится первый. Смысл этой фразы разгадать не удалось. Но опыт подсказывает, что nginx тут ни при чем. From i at trushkin.ru Thu May 30 06:35:04 2013 From: i at trushkin.ru (=?UTF-8?B?0K7RgNC40Lkg0KLRgNGD0YjQutC40L0=?=) Date: Thu, 30 May 2013 10:35:04 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: Расшифровка: В скрипте parser пробовал загрузить через ^file::load, ^curl::load, а также чтобы отвести подозрения от самого парсера, через запуск bash скрипта с попыткой перейти по url через wget. Результат идентичен, т.е. умирает по timeout. Что можно попробовать, чтобы изловить проблему? 30 мая 2013 г., 10:19 пользователь Daniel Podolsky написал: > > Если сделать load страницы по http/https на тестовый скрипт, который в > свою > > очередь попробует загрузить страницу с клиента, последующие запросы > > подвисают и как бы ждут пока завершится первый. > Смысл этой фразы разгадать не удалось. Но опыт подсказывает, что nginx > тут ни при чем. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu May 30 08:02:20 2013 From: nginx-forum at nginx.us (bono90) Date: Thu, 30 May 2013 04:02:20 -0400 Subject: =?UTF-8?B?bmdpbngg0LggdXJsINGB0LXQutGG0LjRjyDQsiDQsNC00YDQtdGB0L3QvtC5INGB?= =?UTF-8?B?0YLRgNC+0LrQtQ==?= Message-ID: <3fd4c6d6f72ba8f39f8eb03981801854.NginxMailingListRussian@forum.nginx.org> Добрый день! Настроил nginx в качестве обратного прокси для доступа к сервису owa (exchange server). Когда набираю в браузере адрес домена, настроенный для использования owa, например: imap.domain.ru - запрос перенаправляется на https://imap.domain.ru/owa/auth/logon.aspx?replaceCurrent=1&url=https://exchange-server.domain.local/owa/. Собственно вопрос как добиться того, чтобы секция URL не присутствовала в адресе (url= https://exchange-server.domain.local/owa/). Конфиг: server { listen 80; server_name imap.domain.ru; rewrite ^/$ https://imap.domain.ru/owa permanent; rewrite ^/owa https://imap.domain.ru/owa permanent; location / {proxy_pass http://127.0.0.1:443;} error_log /var/log/nginx/owa-error.log; access_log /var/log/nginx/owa-access.log; } server { listen 443; server_name imap.domain.ru; # Enable SSL ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; proxy_read_timeout 1800; location / { proxy_pass https://exchange-server.domain.local; } error_log /var/log/nginx/owa-ssl-error.log; access_log /var/log/nginx/owa-ssl-access.log; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239676,239676#msg-239676 From i at trushkin.ru Thu May 30 08:44:15 2013 From: i at trushkin.ru (=?UTF-8?B?0K7RgNC40Lkg0KLRgNGD0YjQutC40L0=?=) Date: Thu, 30 May 2013 12:44:15 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: Чтобы ещё меньше грешить на parser, попробовал запустить процесс, который жрёт много ресурсов и выполняется долго. И зайти на любую страницу, страница не отдаётся пока не завершится предыдущий процесс. Как будто он лочится. Такое может быть? 30 мая 2013 г., 10:35 пользователь Юрий Трушкин написал: > Расшифровка: > > В скрипте parser пробовал загрузить через ^file::load, ^curl::load, а > также чтобы отвести подозрения от самого парсера, через запуск bash скрипта > с попыткой перейти по url через wget. > Результат идентичен, т.е. умирает по timeout. > > Что можно попробовать, чтобы изловить проблему? > > 30 мая 2013 г., 10:19 пользователь Daniel Podolsky написал: > > > Если сделать load страницы по http/https на тестовый скрипт, который в >> свою >> > очередь попробует загрузить страницу с клиента, последующие запросы >> > подвисают и как бы ждут пока завершится первый. >> Смысл этой фразы разгадать не удалось. Но опыт подсказывает, что nginx >> тут ни при чем. >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu May 30 09:08:19 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 30 May 2013 13:08:19 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: > Чтобы ещё меньше грешить на parser, попробовал запустить процесс, который > жрёт много ресурсов и выполняется долго. > И зайти на любую страницу, страница не отдаётся пока не завершится > предыдущий процесс. Как будто он лочится. > Такое может быть? Вы несколько вольно используете терминологию, к сожалению. "страница не отдаётся" - nginx не может отдать статику, пока не завершится тяжелый запрос к fastcgi? не верю :) или fastcgi не обрабатывает новые запросы, пока предыдущий не завершится? тогда вы неправильно сконфигурировали fastcgi. я fastcgi не пользуюсь, но слышал краем уха, что по умолчанию оно запускает один процесс, и, соответственно, обрабатывает один запрос в единицу времени. From slava.kokorin at gmail.com Thu May 30 09:36:13 2013 From: slava.kokorin at gmail.com (Slava Kokorin) Date: Thu, 30 May 2013 13:36:13 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: 30 мая 2013 г., 13:08 пользователь Daniel Podolsky написал: > > Чтобы ещё меньше грешить на parser, попробовал запустить процесс, который > > жрёт много ресурсов и выполняется долго. > > И зайти на любую страницу, страница не отдаётся пока не завершится > > предыдущий процесс. Как будто он лочится. > > Такое может быть? > Вы несколько вольно используете терминологию, к сожалению. > > "страница не отдаётся" - nginx не может отдать статику, пока не > завершится тяжелый запрос к fastcgi? не верю :) > Если это первая страница, то очень может быть. ?Как браузер может запрашивать статику? если он ещё не знает какую ? > или fastcgi не обрабатывает новые запросы, пока предыдущий не > завершится? тогда вы неправильно сконфигурировали fastcgi. я fastcgi > не пользуюсь, но слышал краем уха, что по умолчанию оно запускает один > процесс, и, соответственно, обрабатывает один запрос в единицу > времени. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Regards, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL: From i at trushkin.ru Thu May 30 10:07:37 2013 From: i at trushkin.ru (=?UTF-8?B?0K7RgNC40Lkg0KLRgNGD0YjQutC40L0=?=) Date: Thu, 30 May 2013 14:07:37 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2kg0L/QvtC00LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: Проблема решилась. Неправильно работал fcgiwrap. Действительно дефолтное кол-во соединений 1. Задал опцию -c Number of fcgiwrap processes to prefork Всё работает. Всем спасибо. 30 мая 2013 г., 13:36 пользователь Slava Kokorin написал: > > 30 мая 2013 г., 13:08 пользователь Daniel Podolsky написал: > > > Чтобы ещё меньше грешить на parser, попробовал запустить процесс, который >> > жрёт много ресурсов и выполняется долго. >> > И зайти на любую страницу, страница не отдаётся пока не завершится >> > предыдущий процесс. Как будто он лочится. >> > Такое может быть? >> Вы несколько вольно используете терминологию, к сожалению. >> >> "страница не отдаётся" - nginx не может отдать статику, пока не >> завершится тяжелый запрос к fastcgi? не верю :) >> > > Если это первая страница, то очень может быть. ?Как браузер может > запрашивать статику? если он ещё не знает какую ? > > > >> или fastcgi не обрабатывает новые запросы, пока предыдущий не >> завершится? тогда вы неправильно сконфигурировали fastcgi. я fastcgi >> не пользуюсь, но слышал краем уха, что по умолчанию оно запускает один >> процесс, и, соответственно, обрабатывает один запрос в единицу >> времени. >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > Regards, > Slava > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu May 30 10:18:31 2013 From: nginx-forum at nginx.us (plushka) Date: Thu, 30 May 2013 06:18:31 -0400 Subject: =?UTF-8?B?0J/QvtC40YHQuiDRhNCw0LnQu9C+0LIg0LIg0LrQsNGC0LDQu9C+0LPQsNGF?= Message-ID: Добрый день. Помогите решить задачу: Есть веб-сервер nginx с root /www/ftp/files, который раздает статические файлы (скриншоты). Скринов со временем стало много и я решил разложить из на 2010 | 2011 | 2012 года, в подкаталоги. пример URL - http://screen.tld/files/20101223-ppc-58kb.jpg Дело в том что http://screen.tld/files/ - это root веб-сервера. А сам файл уже перенесен в каталог 2010. Файлов много и не только 2010 года. Как написать конфиг с учетом "пробежать" по подкаталогам в поисках файла и отдать его по ссылке выше? Огромное спасибо, за любую помощь. Если нужны подробности пишите, буду стараться описать подробнее. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239685,239685#msg-239685 From vadim.lazovskiy at gmail.com Thu May 30 10:25:50 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 30 May 2013 14:25:50 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YTQsNC50LvQvtCyINCyINC60LDRgtCw0LvQvtCz0LA=?= =?UTF-8?B?0YU=?= In-Reply-To: References: Message-ID: Здравствуйте. Если список каталогов конечный, то можно забить их все в try_files: location /files/ { location ~ ^/files/(?.*)$ { try_files /files/2013/$filename /files/2012/$filename /files/2011/$filename ...; } } Как-то так. 30 мая 2013 г., 14:18 пользователь plushka написал: > Добрый день. > > Помогите решить задачу: > > Есть веб-сервер nginx с root /www/ftp/files, который раздает статические > файлы (скриншоты). > Скринов со временем стало много и я решил разложить из на 2010 | 2011 | > 2012 года, в подкаталоги. > > пример URL - http://screen.tld/files/20101223-ppc-58kb.jpg > > Дело в том что http://screen.tld/files/ - это root веб-сервера. А сам файл > уже перенесен в каталог 2010. Файлов много и не только 2010 года. Как > написать конфиг с учетом "пробежать" по подкаталогам в поисках файла и > отдать его по ссылке выше? > > Огромное спасибо, за любую помощь. Если нужны подробности пишите, буду > стараться описать подробнее. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,239685,239685#msg-239685 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Thu May 30 10:32:12 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Thu, 30 May 2013 14:32:12 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YTQsNC50LvQvtCyINCyINC60LDRgtCw0LvQvtCz0LA=?= =?UTF-8?B?0YU=?= In-Reply-To: References: Message-ID: Да, последний параметр для try_files - =404, например. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.moskalenko at gmail.com Thu May 30 10:41:22 2013 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Thu, 30 May 2013 13:41:22 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YTQsNC50LvQvtCyINCyINC60LDRgtCw0LvQvtCz0LA=?= =?UTF-8?B?0YU=?= In-Reply-To: References: Message-ID: Если название файла подходит под шаблон YYYYMMDD* то как-то так: location /files { try_files $uri =404; location ~ "^/files/(\d{4})(?.*)$" { try_files /files/$year/$filename =404; } } 2013/5/30 Vadim Lazovskiy : > Да, последний параметр для try_files - =404, например. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Thu May 30 10:57:04 2013 From: nginx-forum at nginx.us (plushka) Date: Thu, 30 May 2013 06:57:04 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YTQsNC50LvQvtCyINCyINC60LDRgtCw0LvQvtCz0LA=?= =?UTF-8?B?0YU=?= In-Reply-To: References: Message-ID: <9078330489f87c536a235c19b6ab5145.NginxMailingListRussian@forum.nginx.org> Спасибо. Очень помогло. Я ходил как раз вокруг да около, подобного try_files. Но нехватило понимания как вывести переменную. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239685,239691#msg-239691 From nginx-forum at nginx.us Thu May 30 10:57:27 2013 From: nginx-forum at nginx.us (plushka) Date: Thu, 30 May 2013 06:57:27 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YTQsNC50LvQvtCyINCyINC60LDRgtCw0LvQvtCz0LA=?= =?UTF-8?B?0YU=?= In-Reply-To: References: Message-ID: Спасибо. Тоже очень хороший вариант. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239685,239692#msg-239692 From nginx-forum at nginx.us Fri May 31 06:19:24 2013 From: nginx-forum at nginx.us (SergeyR) Date: Fri, 31 May 2013 02:19:24 -0400 Subject: =?UTF-8?B?0JfQsNC60YDRi9GC0Ywg0LTQvtGB0YLRg9C/INC6INC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjQuCDQvdCwINCy0YHQtdC8INGB0LXRgNCy0LXRgNC1?= Message-ID: <68a08547b285d86e7c52ee408a7c0099.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Не могу разобраться как настроить nginx для закрытия директории на время. Идет подбор паролей к десяткам сайтов на Joomla - /administrator/index.php Как правильно закрыть или ограничить доступ к директории /administrator/ на всем сервере? location /administrator/ { deny all; } не работает. Подскажите кто знает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239708,239708#msg-239708 From nginx-ru at sadok.spb.ru Fri May 31 06:43:36 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Fri, 31 May 2013 10:43:36 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQutGA0YvRgtGMINC00L7RgdGC0YPQvyDQuiDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lgg0L3QsCDQstGB0LXQvCDRgdC10YDQstC10YDQtQ==?= In-Reply-To: <68a08547b285d86e7c52ee408a7c0099.NginxMailingListRussian@forum.nginx.org> References: <68a08547b285d86e7c52ee408a7c0099.NginxMailingListRussian@forum.nginx.org> Message-ID: <1823568967.20130531104336@sadok.spb.ru> Здравствуйте, SergeyR. Вы писали 31 мая 2013 г., 10:19:24: > Здравствуйте! > Не могу разобраться как настроить nginx для закрытия директории на время. > Идет подбор паролей к десяткам сайтов на Joomla - /administrator/index.php > Как правильно закрыть или ограничить доступ к директории /administrator/ на > всем сервере? > location /administrator/ { > deny all; > } > не работает. Вероятно, попадает в какой-нить location ~ \.php$ { .... } -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Fri May 31 09:43:27 2013 From: nginx-forum at nginx.us (schaos) Date: Fri, 31 May 2013 05:43:27 -0400 Subject: =?UTF-8?B?cHJveHkgcmVkaXJlY3Qg0L3QtSDQv9GA0L7QuNGB0YXQvtC00LjRgiDQuNC30Lw=?= =?UTF-8?B?0LXQvdC10L3QuNC1IExvY2F0aW9u?= Message-ID: Доброго дня. пожалуйста помогите с задачей При обращении к прокси адрес имеет следующий вид http://proxy/хост и порт куда отправится запрос/запрос Использую следующий конфиг location ~ ^/(.*)/(.*)$ { set $domain $1; set $urlmain $2; proxy_pass http://$domain/$urlmain; proxy_redirect http://$domain http://$host:$server_port/$domain; } При обращении к прокси все обрабатывется хорошо до момента подмены Location в ответе проксируемого сервера, подмена просто не происходит. Как правильно настроить proxy_redirect в данном случае? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239714,239714#msg-239714 From dmitriy at lyalyuev.info Fri May 31 11:09:05 2013 From: dmitriy at lyalyuev.info (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JvRj9C70Y7QtdCy?=) Date: Fri, 31 May 2013 14:09:05 +0300 Subject: SPDY over HTTP Message-ID: Добрый день. Тут спор возник с коллегой. SPDY работает только поверх SSL или через HTTP тоже возможно? Сейчас понятное дело, что только по SSL. А вообще как оно должно быть по стандарту? Вроде как там нет четкой привязки к SSL. Ткните носом как правильно, плз. -- С уважением, Дмитрий Лялюев тел. +380 (66) 532-29-62 Все контакты для связи на http://lyalyuev.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri May 31 11:32:04 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 31 May 2013 15:32:04 +0400 Subject: SPDY over HTTP In-Reply-To: References: Message-ID: <201305311532.05034.vbart@nginx.com> On Friday 31 May 2013 15:09:05 Дмитрий Лялюев wrote: > Добрый день. > > Тут спор возник с коллегой. SPDY работает только поверх SSL или через HTTP > тоже возможно? > > Сейчас понятное дело, что только по SSL. А вообще как оно должно быть по > стандарту? Вроде как там нет четкой привязки к SSL. > > Ткните носом как правильно, плз. SPDY не работает по HTTP по той же причине, почему он не работает по HTTPS. Но я догадываюсь, что вопрос был о том, работает ли SPDY по plain TCP. Об этом ликбез уже был, смотрите тут: http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050114.html -- Валентин Бартенев http://nginx.org/en/donation.html From vbart at nginx.com Fri May 31 12:14:21 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 31 May 2013 16:14:21 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0ICDQvdC1INC/0YDQvtC40YHRhdC+0LTQuNGCINC4?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: References: Message-ID: <201305311614.21203.vbart@nginx.com> On Friday 31 May 2013 13:43:27 schaos wrote: > Доброго дня. > пожалуйста помогите с задачей > > При обращении к прокси адрес имеет следующий вид http://proxy/хост и порт > куда отправится запрос/запрос > Использую следующий конфиг > location ~ ^/(.*)/(.*)$ { > set $domain $1; > set $urlmain $2; location ~ ^/(?.*)/(?.*)$ { > proxy_pass http://$domain/$urlmain; > proxy_redirect http://$domain http://$host:$server_port/$domain; > } > При обращении к прокси все обрабатывется хорошо до момента подмены Location > в ответе проксируемого сервера, подмена просто не происходит. > Как правильно настроить proxy_redirect в данном случае? > Спасибо. > Какая версия nginx? -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri May 31 13:02:34 2013 From: nginx-forum at nginx.us (schaos) Date: Fri, 31 May 2013 09:02:34 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0INC90LUg0L/RgNC+0LjRgdGF0L7QtNC40YIg0Lg=?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: <201305311614.21203.vbart@nginx.com> References: <201305311614.21203.vbart@nginx.com> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Friday 31 May 2013 13:43:27 schaos wrote: > > Доброго дня. > > пожалуйста помогите с задачей > > > > При обращении к прокси адрес имеет следующий вид http://proxy/хост и > порт > > куда отправится запрос/запрос > > Использую следующий конфиг > > location ~ ^/(.*)/(.*)$ { > > set $domain $1; > > set $urlmain $2; > > location ~ ^/(?.*)/(?.*)$ { > > > > proxy_pass http://$domain/$urlmain; > > proxy_redirect http://$domain > http://$host:$server_port/$domain; > > } > > При обращении к прокси все обрабатывется хорошо до момента подмены > Location > > в ответе проксируемого сервера, подмена просто не происходит. > > Как правильно настроить proxy_redirect в данном случае? > > Спасибо. > > > > Какая версия nginx? > > -- > Валентин Бартенев > http://nginx.org/en/donation.html > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru извинте сразу не указал ОС Centos 6.2 nginx 1.0.15-5.el6 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239720,239723#msg-239723 From vbart at nginx.com Fri May 31 13:53:29 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 31 May 2013 17:53:29 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0ICDQvdC1INC/0YDQvtC40YHRhdC+0LTQuNGCINC4?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: References: <201305311614.21203.vbart@nginx.com> Message-ID: <201305311753.29777.vbart@nginx.com> On Friday 31 May 2013 17:02:34 schaos wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > On Friday 31 May 2013 13:43:27 schaos wrote: > > > Доброго дня. > > > пожалуйста помогите с задачей > > > > > > При обращении к прокси адрес имеет следующий вид http://proxy/хост и > > > > порт > > > > > куда отправится запрос/запрос > > > Использую следующий конфиг > > > location ~ ^/(.*)/(.*)$ { > > > > > > set $domain $1; > > > set $urlmain $2; > > > > location ~ ^/(?.*)/(?.*)$ { > > > > > proxy_pass http://$domain/$urlmain; > > > proxy_redirect http://$domain > > > > http://$host:$server_port/$domain; > > > > > } > > > > > > При обращении к прокси все обрабатывется хорошо до момента подмены > > > > Location > > > > > в ответе проксируемого сервера, подмена просто не происходит. > > > Как правильно настроить proxy_redirect в данном случае? > > > Спасибо. > > > > Какая версия nginx? > > > > извинте сразу не указал > ОС Centos 6.2 > nginx 1.0.15-5.el6 > Смените антиквариат на актуальную версию, и всё будет работать. Поддержка переменных в первом параметре директивы proxy_redirect появилась примерно два года назад (1.1.11+). RPM брать тут: http://nginx.org/ru/linux_packages.html -- Валентин Бартенев http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri May 31 14:40:10 2013 From: nginx-forum at nginx.us (schaos) Date: Fri, 31 May 2013 10:40:10 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0INC90LUg0L/RgNC+0LjRgdGF0L7QtNC40YIg0Lg=?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: <201305311753.29777.vbart@nginx.com> References: <201305311753.29777.vbart@nginx.com> Message-ID: Спасибо огромное Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239720,239727#msg-239727 From denis at webmaster.spb.ru Fri May 31 16:48:29 2013 From: denis at webmaster.spb.ru (denis) Date: Fri, 31 May 2013 20:48:29 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0ICDQvdC1INC/0YDQvtC40YHRhdC+0LTQuNGCINC4?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: <201305311753.29777.vbart@nginx.com> References: <201305311614.21203.vbart@nginx.com> <201305311753.29777.vbart@nginx.com> Message-ID: <51A8D45D.7070209@webmaster.spb.ru> 31.05.2013 17:53, Валентин Бартенев пишет: > >> извинте сразу не указал >> ОС Centos 6.2 >> nginx 1.0.15-5.el6 >> > Смените антиквариат на актуальную версию, и всё будет работать. Вы ещё дебилян не видели :) cat /etc/debian_version 6.0.7 nginx -v nginx version: nginx/0.7.67 вот где г-но мамонта. А 1.0.* это уже почти свежак ))) From vadim.lazovskiy at gmail.com Fri May 31 16:59:45 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 31 May 2013 20:59:45 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5IHJlZGlyZWN0INC90LUg0L/RgNC+0LjRgdGF0L7QtNC40YIg0Lg=?= =?UTF-8?B?0LfQvNC10L3QtdC90LjQtSBMb2NhdGlvbg==?= In-Reply-To: <51A8D45D.7070209@webmaster.spb.ru> References: <201305311614.21203.vbart@nginx.com> <201305311753.29777.vbart@nginx.com> <51A8D45D.7070209@webmaster.spb.ru> Message-ID: Здравствуйте. В debian еще, вроде, нет пакета без сторонних модулей. Лично я использую репы http://nginx.org/en/linux_packages.html#stable чего и вам всем желаю. 31 мая 2013 г., 20:48 пользователь denis написал: > 31.05.2013 17:53, Валентин Бартенев пишет: > > >> извинте сразу не указал >>> ОС Centos 6.2 >>> nginx 1.0.15-5.el6 >>> >>> Смените антиквариат на актуальную версию, и всё будет работать. >> > Вы ещё дебилян не видели :) > cat /etc/debian_version > 6.0.7 > > nginx -v > nginx version: nginx/0.7.67 > > вот где г-но мамонта. А 1.0.* это уже почти свежак ))) > > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: