Блог

Главная - Вопросы по программированию - Длинные URL-адреса работают с запросами Python, но не CURL или веб-браузерами (nginx-uwsgi-django)

Длинные URL-адреса работают с запросами Python, но не CURL или веб-браузерами (nginx-uwsgi-django)

#nginx #url #get #uwsgi

#nginx #url #получить #uwsgi

Вопрос:

Я хочу включить относительно длинные URL-адреса для работы на моем сайте.

В Python это работает довольно хорошо:

 import requests


base_url = 'https://myurl.com'
client = requests.session()
gs = ['FAM20558-i1-1.1']


for i in [100,1000,1100]:
    r = client.get(url=f'{base_url}/api/validate-genomes', params={'genomes[]': gs * i})
    print(i, r.text)

Вывод:

 100 {"success": true}
1000 {"success": true}
1100 <html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.14.1</center>
</body>
</html>

Так что все работает нормально, пока i=1000 это все, что мне нужно.

Для i=300 URL-адреса длиной 9071 символ. Размер в соответствии с sys.getsizeof: 9120 байт. Это выглядит так: https://myurl.com/api/validate-genomes/?genomes[]=FAM20558-i1-1.1amp;genomes[]=FAM20558-i1-1.1amp;...

Но когда я пытаюсь СВЕРНУТЬ URL-адрес или скопировать этот URL-адрес в браузер, это не сработает! Запросы ajax с такой длиной также не работают. Почему это так? Как я могу это исправить? (Запросы с i=100 всегда работают.)

CURL output ( curl --http2 -v $URL ):

 > Host: myurl.com
> user-agent: curl/7.71.1
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (52) Empty reply from server

В nginx access.log я вижу:

 <MY IP> - - [04/Feb/2021:11:06:58  0100] "-" 000 0 "-" "-" "-"

Никаких изменений в nginx error.log.

Соответствующая конфигурация nginx (не уверен, что это имеет значение):

 upstream django {
    server unix:///path/to/socket.sock;
}

server {
    listen       443 ssl http2 default_server;

    client_max_body_size        10M;

    uwsgi_buffer_size           128k;
    uwsgi_buffers               12 128k;
    uwsgi_busy_buffers_size     256k;

    client_header_buffer_size   5120k;
    large_client_header_buffers 16 5120k;

    location / {
        uwsgi_pass django;
        include /etc/nginx/uwsgi_params;
    }
}

#РЕДАКТИРОВАТЬ: я понимаю, что в этом случае запросы POST имеют больше смысла. Но мне нужны длинные URL-адреса в другом месте, и это удобный способ продемонстрировать проблему.

Ответ №1:

Если я указал --http1.1 в запросе CURL, это сработало! Проблема была с http2. Нашел решение здесь: https://phabricator.wikimedia.org/T209590

Мне пришлось увеличить http2_max_field_size и http2_max_header_size в моей конфигурации nginx.