Как разрешить в nginx GET-запросы больше 5400 байт?

Question

Վիտալի Լագունով @vitaliy2

Nginx

Как разрешить в nginx GET-запросы больше 5400 байт?

Когда суммарно query + все заголовки превышают примерно 5400 байт, nginx не отдаёт ответ и соединение закрывается (даже ошибку не выдаёт).

Пробовал:

client_header_buffer_size 32k;
large_client_header_buffers 4 64k;
client_max_body_size 1m;
client_body_buffer_size 1m;
комментить использование $args

Ничего не помогает. Бекенда нет, отдаётся статичный html-файл. Никто не знает причины? Или это сам браузер лимитит?

PS. Советующим POST — я знаю для чего POST, а для чего GET. В моём случае это строка поискового запроса, которая должна присутствовать в URL, чтобы пользователь мог скопировать и сохранить эту ссылку. POST здесь не подойдёт.

Вопрос задан более трёх лет назад
590 просмотров

8 комментариев

Подписаться 1 Простой 8 комментариев

Lynn «Кофеман» @Lynn

А это точно nginx, а не браузер?

Написано более трёх лет назад
Alex McArrow @AlexMcArrow

vitaliy2, Просто пожелание - не стоит столько передавать через GET, а для таких объемов данных есть POST.
И тут даже не проблема заставить NGINX обрабатывать такие заголовки, а то что не все браузеры смогут отдать их.

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

Alex McArrow, POST в моём случае не подходит, т. к. это строка поискового запроса, которая должна присутствовать в URL, чтобы пользователь мог скопировать и сохранить эту ссылку.

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

Алексей Тен, я пробовал в FF и Chrome, и при этом и там, и там 3 байта в GET-параметрах играли разницу в одном и том же месте. Хотя это не гарантирует, что не в браузерах дело.

Написано более трёх лет назад
Alex McArrow @AlexMcArrow

vitaliy2, тогда думайте над сокращением ключей и параметров (param1 = p1 и т.д.), вплоть до преобразования каждого такого УРЛа в котроткий вариант (hash - указывающий на весь набор параметров - пример: https://jqueryui.com/themeroller/#!zThemeParams=5d... или https://themeroller.jquerymobile.com:443/?ver=1.4....

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

Alex McArrow, я уже итак подумал и преобразовываю в base64, что помогло сократить размер в 3.5 раза. Запрос вмещает 1500 символов, но если можно просто взять и снять ограничение, это было бы неплохо. Вот поэтому я и спрашиваю.

Использование параметров после hash (#) не пойдёт, т. к. 1) некрасиво, 2) плохо работает (нажал Enter и страница не обновляется, т. е. поведение явно отличается от стандартного), 3) требует затрат по переделыванию.

По идее браузеры вроде 32 или 64 КБ поддерживают. А я получаю только 4 КБ. Если бы браузеры не поддерживали, то ладно, не так страшно, а раз поддерживают, то хочется знать, какая настройка в nginx влияет.

Написано более трёх лет назад
Alex McArrow @AlexMcArrow

vitaliy2, я понимаю вас и ваше рвение сделать "меньшей кровью", но это выйдет вам "боком" позже, когда параметров станет ЕЩЕ больше.
Задумайтесь над сменой алгоритма работы системы, сейчас - чем когда будет "поздно".
По существу вашего рвения - large_client_header_buffers 4 64k именно этот параметр отвечает за размерность заголовка. Но стоит понимать что это только фронт, возможно у вас NGINX работает как прокси, тогда настройки требуются за следующем этапе (следующий веб-сервер Apache или NGINX), а так же над тем что все это "счастье" вы прокидываете в бекэнд (PHP, NodeJS) - а как он относится к таким объемам данных?? Может быть проблема там?

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

Alex McArrow, у меня один параметр, куда больше) Ну каюсь, есть ещё другой параметр весом 1 байт.

Возможно у вас NGINX работает как прокси

Да, забыл упомянуть, отдаётся статичный html-файл. Никакого бэкэнда нет.

рвение сделать "меньшей кровью"

У меня нет рвения что-то сделать. У меня есть рвение поменять настройку, ну и просто узнать, какая настройка может влиять. Сама проблема не так критична, т. к. большинство запросов до 500-3000 символов, а получившиеся 1500 символов — тоже не так плохо.

Написано более трёх лет назад

Пригласить эксперта

Ответы на вопрос 2

4 комментария

Վիտալի Լագունով @vitaliy2 Автор вопроса

Использование POST в этом случае невозможно в принципе. Это строка поискового запроса, она должна быть в URL, чтобы пользователь мог её скопировать и сохранить себе.

Написано более трёх лет назад
key don @keydon2

vitaliy2, опишите задачу. Мб вам подойдет хэширование.

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

key don, я описал в комментах под вопросом. Хэширование могло бы подойти, если бы поддержка длинных URL была бы позарез нужна. Но в моей задаче портить красоту и юзабельность из-за того, что я не могу найти нужную настройку в nginx — это бред.

Ну и вообще, хэш предназначен для прыжка на заголовки. Это использование не по назначению.

Написано более трёх лет назад
Վիտալի Լագունով @vitaliy2 Автор вопроса

Все вместо ответа отвечают как перестать использовать длинные ссылки. А вопрос был не в этом. У меня тот редкий случай, когда длинные ссылки на 99% подходят лучше всех.

Пользователь вводит поисковый запрос, к примеру, на 2000 символов. И хочет сохранить ссылку на этот запрос.

Нет, кто-то скажет "сохраните тогда ссылку на сервере". Но ссылка обновляется после каждого ввода символа, а ответы показываются мгновенно. Это ж сколько ссылок пришлось бы сохранить.

Браузеры вроде поддерживают 32 или 64 КБ в GET. Если поддерживают, почему бы этим не воспользоваться? Я конечно не надеялся на ответ, но…
Ладно, сам потом попытаюсь по логам посмотреть, может там чё-то будет.

Написано более трёх лет назад

Комментировать

Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации

Похожие вопросы

Nginx

Простой
Запрос статичной картинки не зная формата?
- 1 подписчик
- 19 апр.
- 71 просмотр
1

ответ
Nginx

Простой
Как настроить nginx forward proxy?
- 1 подписчик
- 16 апр.
- 114 просмотров
2

ответа
Nginx

Простой
Как не записывать в логи Nginx юзеров с юзер агентом yandex?
- 1 подписчик
- 13 апр.
- 96 просмотров
1

ответ
PHP

+2 ещё

Простой
Почему PHP-скрипт зависает/завершается на паузе (sleep)?
- 1 подписчик
- 11 апр.
- 128 просмотров
2

ответа
Linux

+1 ещё

Простой
Как расчитывать размеры кэшей и буферов в nginx?
- 3 подписчика
- 11 апр.
- 536 просмотров
1

ответ
Сетевое администрирование

+4 ещё

Средний
Ошибка доступности сайта. Проблема с доменами. Как исправить?
- 1 подписчик
- 10 апр.
- 164 просмотра
1

ответ
Nginx

Простой
Убрать слеш в конце домена (nginx). На внутренних страницах работает, site.ru/ нет?
- 1 подписчик
- 10 апр.
- 66 просмотров
0

ответов
Nginx

Простой
Как получать нужные данные в access_log?
- 1 подписчик
- 09 апр.
- 58 просмотров
1

ответ
Nginx

+1 ещё

Простой
Как избежать падения nginx при отсутствии backend, proxy_pass контейнера?
- 1 подписчик
- 09 апр.
- 84 просмотра
1

ответ
Nginx

+1 ещё

Простой
Primary script unknown. Ошибка настройки путей nginx. Почему?
- 1 подписчик
- 07 апр.
- 39 просмотров
1

ответ
Показать ещё Загружается…

Системный администратор

А5000 Event Solutions • Москва

от 100 000 до 150 000 ₽

Прикладной администратор SberApps

Сбер • Москва

от 230 000 ₽

DevOps-инженер

Автошкола «Светофор»

от 80 000 ₽

Настроить перехват https-трафика для android-приложения

25 апр. 2024, в 01:02

10000 руб./за проект

Программа (скрипт) для автоматизации торговли Solana

25 апр. 2024, в 00:45

100 руб./в час

Телеграм-Бот для выдачи конфигов VPN (VLESS/Reality)

25 апр. 2024, в 00:32

10000 руб./за проект

vitaliy2, Просто пожелание - не стоит столько передавать через GET, а для таких объемов данных есть POST.
И тут даже не проблема заставить NGINX обрабатывать такие заголовки, а то что не все браузеры смогут отдать их.
Alex McArrow, POST в моём случае не подходит, т. к. это строка поискового запроса, которая должна присутствовать в URL, чтобы пользователь мог скопировать и сохранить эту ссылку.
Алексей Тен, я пробовал в FF и Chrome, и при этом и там, и там 3 байта в GET-параметрах играли разницу в одном и том же месте. Хотя это не гарантирует, что не в браузерах дело.
vitaliy2, тогда думайте над сокращением ключей и параметров (param1 = p1 и т.д.), вплоть до преобразования каждого такого УРЛа в котроткий вариант (hash - указывающий на весь набор параметров - пример: https://jqueryui.com/themeroller/#!zThemeParams=5d... или https://themeroller.jquerymobile.com:443/?ver=1.4....
Alex McArrow, я уже итак подумал и преобразовываю в base64, что помогло сократить размер в 3.5 раза. Запрос вмещает 1500 символов, но если можно просто взять и снять ограничение, это было бы неплохо. Вот поэтому я и спрашиваю.

Использование параметров после hash (#) не пойдёт, т. к. 1) некрасиво, 2) плохо работает (нажал Enter и страница не обновляется, т. е. поведение явно отличается от стандартного), 3) требует затрат по переделыванию.

По идее браузеры вроде 32 или 64 КБ поддерживают. А я получаю только 4 КБ. Если бы браузеры не поддерживали, то ладно, не так страшно, а раз поддерживают, то хочется знать, какая настройка в nginx влияет.
vitaliy2, я понимаю вас и ваше рвение сделать "меньшей кровью", но это выйдет вам "боком" позже, когда параметров станет ЕЩЕ больше.
Задумайтесь над сменой алгоритма работы системы, сейчас - чем когда будет "поздно".
По существу вашего рвения - large_client_header_buffers 4 64k именно этот параметр отвечает за размерность заголовка. Но стоит понимать что это только фронт, возможно у вас NGINX работает как прокси, тогда настройки требуются за следующем этапе (следующий веб-сервер Apache или NGINX), а так же над тем что все это "счастье" вы прокидываете в бекэнд (PHP, NodeJS) - а как он относится к таким объемам данных?? Может быть проблема там?
Alex McArrow, у меня один параметр, куда больше) Ну каюсь, есть ещё другой параметр весом 1 байт.

Возможно у вас NGINX работает как прокси

Да, забыл упомянуть, отдаётся статичный html-файл. Никакого бэкэнда нет.

рвение сделать "меньшей кровью"

У меня нет рвения что-то сделать. У меня есть рвение поменять настройку, ну и просто узнать, какая настройка может влиять. Сама проблема не так критична, т. к. большинство запросов до 500-3000 символов, а получившиеся 1500 символов — тоже не так плохо.