Re: Как обработать редирект и проксировать результат приложению?
Не проверял. GET работает, как ожидается. Для решения моей проблемы этого
достаточно.
пн, 29 июн. 2020 г. в 10:48, Илья Шипицин :
> я примерно такое имел в виду.
>
> а вот расскажите, как будет работать, если на POST запрос будет 301, вы в
> @handle_redirect отправите тоже POST ?
>
> пн, 29 июн. 2020 г. в 12:03, Александр Карабанов >:
>
>> Вот такое решение нашёл:
>>
>> https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx
>>
>> server {
>> ...
>>
>> location / {
>> proxy_pass http://backend;
>> # You may need to uncomment the following line if your redirects are
>> relative, e.g. /foo/bar#proxy_redirect / /;
>> proxy_intercept_errors on;
>> error_page 301 302 307 = @handle_redirect;
>> }
>>
>> location @handle_redirect {
>> set $saved_redirect_location '$upstream_http_location';
>> proxy_pass $saved_redirect_location;
>> }}
>>
>>
>> пт, 26 июн. 2020 г. в 15:57, Илья Шипицин :
>>
>>> это не во всех случаях можно сделать корректно.
>>>
>>> например, 301 по RFC можно отвечать только на GET. а если сервер ответил
>>> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или
>>> GET ?
>>> вот именно этот выбор и доносится до клиента, когда 301 транслируется
>>> один в один.
>>>
>>> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его
>>> на локейшен, и в локейшене сделать proxy_pass
>>> но это очень скользкая дорожка
>>>
>>> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов <
>>> zend.karaba...@gmail.com>:
>>>
Здравствуйте.
Приложению запрещено самостоятельно открывать соединения с внешним
миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx
проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать
соединение за счёт keepalive и не открывать новое соединение на каждый
запрос от приложения).
Возникла ситуация, когда целевой хост стал отвечать 301 редиректом,
естественно приложение, получив вместо ожидаемого контента, 301 редирект
сломалось.
Есть ли способ заставить Nginx обработать редирект самостоятельно и
отдать приложению готовый контент?
--
С уважением,
Александр Карабанов
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> --
>> С уважением,
>> Александр Карабанов
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
С уважением,
Александр Карабанов
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_ssl_server_name
Hello! On Sun, Jun 28, 2020 at 09:46:14PM +0300, Gena Makhomed wrote: > Максим, а зачем по-умолчанию сделано proxy_ssl_server_name off; ? На то есть две причины: 1. Исторически nginx не умел SNI в соединениях с бэкендами. Когда поддержка была добавлена - поведение по умолчанию было оставлено "как есть", дабы не ломать существующие конфигурации, где это может оказаться важно. 2. Использование SNI означает передачу имени сервера открытым текстом, что в общем случае - утечка данных. Если мы хотим шифровать трафик с бэкендами - странно допускать подобную утечку по умолчанию. > Что-то сломается, если сделать по-умолчанию proxy_ssl_server_name on; ? Скорее всего нет, но может. > Применил на одном из серверов workaround > https://trac.nginx.org/nginx/ticket/195#comment:6 > > В результате - один из сервисов защиты от DDoS прислал уведомление, > что сайт не работает, потому что у них, по всей видимости в конфиге > все настроено по-умолчанию proxy_ssl_server_name off; и это стало > причиной проблем. Подробнее об этом написано в том же 195 тикете: > https://trac.nginx.org/nginx/ticket/195#comment:11 Если у вас среди клиентов есть те, кто не использует SNI - не надо запрещать соединения без SNI. Описанное в тикете решение с "ssl_ciphers aNULL;" совершенно не обязательно применять в сервере по умолчанию, а если всё-таки применять - то стоит понимать последствия. Что до "сервисов защиты", то почему они не используют SNI - это вопрос к ним, а не к настройкам по умолчанию nginx'а. Настройки по умолчанию расчитаны на работу с собственными бэкендами, и если там используется nginx - они так или иначе должны были много что менять. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ssl_protocols
Hello! On Sun, Jun 28, 2020 at 09:26:46PM +0300, Gena Makhomed wrote: > On 25.06.2020 22:27, Maxim Dounin wrote: > > > А не разрешить ли TLSv1.3 по умолчанию. Сейчас для этого как > > минимум один блокер - в TLSv1.3 не настраиваются шифры и в > > результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее > > тут: > > > > http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html > > В ответе https://trac.nginx.org/nginx/ticket/195#comment:6 можно > же дописать, что этот workaround не работает для протокола TLSv1.3, > потому что протокол TLSv1.3 вообще не поддерживает ssl_ciphers aNULL; > > Хотя, в этом тикете https://trac.nginx.org/nginx/ticket/195 просили > совсем о другом - просили сделать возможность refuse_connections > в том случае, если приходит HTTPS-запрос в nginx на HTTP-only сайт, > то есть просят сделать "strict SNI should really be implemented. It's just a > few if statements, is this too much for a long-standing issue?" > > Не смотря на то, что этот тикет был создан 8 лет тому назад - такая > проблема актуальна и сегодня, потому что, насколько мне известно, > Google индексирует сайты по HTTPS не обращая внимания на ошибки > несоответствия сертификата. В резхультате в его поисковой выдаче > будет очень много страниц, которые дают ошибку TLS/SSL в браузере. Проблем с гуглом при использовании "ssl_ciphers aNULL; return 444;" - не обнаружено, да и быть не может: соединение так или иначе закрывается, даже если гугл вдруг готов общаться по шифрам aNULL. Семантически эта конструкция делает именно то, что нужно: отказывается общаться, не предъявляя сертификата. То есть в отсутствии TLSv1.3 этот workaround работает именно так, как надо. Включение TLSv1.3 - его ломает. Соответственно для включения TLSv1.3 по умолчанию надо решить две проблемы: 1. Сделать решение, которое бы позволило реализовать ту же семантику "отазаться общаться, не предъявляя сертификата" в условиях наличия TLSv1.3. 2. Придумать решение для существующих конфигураций с "ssl_ciphers aNULL; return 444;". > > в TLSv1.3 не настраиваются шифры > > И если быть уж совсем точным, шифры в TLSv1.3 настраиваются. > Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема > только в том, что вот разработчики nginx не могут договориться > с разработчиками OpenSSL о том, как эти шифры необходимо настраивать. > > В том же Apache можно без проблем настроить шифры для TLSv1.3: > https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite > > Если никак не получается договориться с разработчиками OpenSSL, > может быть имеет сделать смысл форк OpenSSL иил написать с нуля > свою собственную библиотеку? Ведь когда-то так и nginx появился, > когда стало понятно, что apache не подходит для некоторых задач. > > Или пойти по пути Apache, сделав возможность раздельной настройки > шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества > времени уже стало понятно, что разработчики OpenSSL свою точку зрения > по этому вопросу менять не собираются и в OpenSSL все будет так же. В тикете тут: https://trac.nginx.org/nginx/ticket/1529 и связанных тикетах - достаточно подробно расписано, что настраивается, что не настраивается (в BoringSSL, например, для TLSv1.3 не настраивается вообще ничего), и что именно я думаю по этому поводу. Не вижу смысла тут повторяться. Сама по себе невозможность насраивать шифры - не является препятствием для включения TLSv1.3 по умолчанию, препятствием являются возникающие в результае проблемы в конфигурациях с "ssl_ciphers aNULL;". -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как обработать редирект и проксировать результат приложению?
я примерно такое имел в виду.
а вот расскажите, как будет работать, если на POST запрос будет 301, вы в
@handle_redirect отправите тоже POST ?
пн, 29 июн. 2020 г. в 12:03, Александр Карабанов :
> Вот такое решение нашёл:
>
> https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx
>
> server {
> ...
>
> location / {
> proxy_pass http://backend;
> # You may need to uncomment the following line if your redirects are
> relative, e.g. /foo/bar#proxy_redirect / /;
> proxy_intercept_errors on;
> error_page 301 302 307 = @handle_redirect;
> }
>
> location @handle_redirect {
> set $saved_redirect_location '$upstream_http_location';
> proxy_pass $saved_redirect_location;
> }}
>
>
> пт, 26 июн. 2020 г. в 15:57, Илья Шипицин :
>
>> это не во всех случаях можно сделать корректно.
>>
>> например, 301 по RFC можно отвечать только на GET. а если сервер ответил
>> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или
>> GET ?
>> вот именно этот выбор и доносится до клиента, когда 301 транслируется
>> один в один.
>>
>> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его
>> на локейшен, и в локейшене сделать proxy_pass
>> но это очень скользкая дорожка
>>
>> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов <
>> zend.karaba...@gmail.com>:
>>
>>> Здравствуйте.
>>>
>>> Приложению запрещено самостоятельно открывать соединения с внешним
>>> миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx
>>> проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать
>>> соединение за счёт keepalive и не открывать новое соединение на каждый
>>> запрос от приложения).
>>> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом,
>>> естественно приложение, получив вместо ожидаемого контента, 301 редирект
>>> сломалось.
>>> Есть ли способ заставить Nginx обработать редирект самостоятельно и
>>> отдать приложению готовый контент?
>>> --
>>> С уважением,
>>> Александр Карабанов
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> С уважением,
> Александр Карабанов
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как обработать редирект и проксировать результат приложению?
Вот такое решение нашёл:
https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx
server {
...
location / {
proxy_pass http://backend;
# You may need to uncomment the following line if your
redirects are relative, e.g. /foo/bar#proxy_redirect / /;
proxy_intercept_errors on;
error_page 301 302 307 = @handle_redirect;
}
location @handle_redirect {
set $saved_redirect_location '$upstream_http_location';
proxy_pass $saved_redirect_location;
}}
пт, 26 июн. 2020 г. в 15:57, Илья Шипицин :
> это не во всех случаях можно сделать корректно.
>
> например, 301 по RFC можно отвечать только на GET. а если сервер ответил
> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или
> GET ?
> вот именно этот выбор и доносится до клиента, когда 301 транслируется один
> в один.
>
> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его
> на локейшен, и в локейшене сделать proxy_pass
> но это очень скользкая дорожка
>
> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов >:
>
>> Здравствуйте.
>>
>> Приложению запрещено самостоятельно открывать соединения с внешним миром.
>> Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот
>> запрос на целевой хост (это сделано, чтобы переиспользовать соединение за
>> счёт keepalive и не открывать новое соединение на каждый запрос от
>> приложения).
>> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом,
>> естественно приложение, получив вместо ожидаемого контента, 301 редирект
>> сломалось.
>> Есть ли способ заставить Nginx обработать редирект самостоятельно и
>> отдать приложению готовый контент?
>> --
>> С уважением,
>> Александр Карабанов
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
С уважением,
Александр Карабанов
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
