Hello!
On Mon, Mar 16, 2020 at 03:14:10PM +0300, Evgeniy Berdnikov wrote:
> On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote:
> > В данном случае я бы скорее предположил, что 400 возвращает
> > бекенд. В отладочном логе, это, безусловно, будет явно видно, но
>
> В данном случае т
On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote:
> В данном случае я бы скорее предположил, что 400 возвращает
> бекенд. В отладочном логе, это, безусловно, будет явно видно, но
В данном случае товарищ посылает plain http на 443-й порт, который,
несомненно, сконфигурён как ssl, п
да, вы правы. Проверил - 400 отдает апстрим в данном случае.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287264,287361#msg-287361
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Hello!
On Mon, Mar 16, 2020 at 12:54:33PM +0500, Илья Шипицин wrote:
> еще раз - "400 bad request" во многих случаях можно подсмотреть по
> error.log (на всякий случай запустите отладочную сборку nginx).
> если у вас будет 400, но в error.log тишина, то вы сузили количество
> возможных вариантов
в последнее время какая-то странная мода игнорировать советы (кстати, они
были неплохие).
еще раз - "400 bad request" во многих случаях можно подсмотреть по
error.log (на всякий случай запустите отладочную сборку nginx).
если у вас будет 400, но в error.log тишина, то вы сузили количество
возможны
Хорошо, сделал по другому - нашел несколько сторонних сервисов, в которых
можно узакать УРЛ ресурса и типа запроса. Абсолютно все возвращают "HTTP/1.1
400 Bad Request". Я конечно не знаю как они работают, но неужели все такие
же косорукие как и я? :) Dmytro Lavryk тоже говорит, что у него аналогичн