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

Question

[Վիտալի Լագունով]

Когда суммарно 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 здесь не подойдёт.

Comments

[Lynn «Кофеман»]

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

[Alex McArrow]

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

[Վիտալի Լագունով]

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

[Վիտալի Լագունով]

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

[Alex McArrow]

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 влияет.

[Alex McArrow]

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

[Վիտալի Լագունով]

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

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

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

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

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

Answer 1

[Fixid]

Не ищите проблему на ровном месте, используйте POST который именно для этого и предназначен

Comments

[Վիտալի Լագունով]

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

[key don]

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

[Վիտալի Լագունով]

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

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

[Վիտալի Լագունով]

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

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

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

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

Answer 2

[key don]

Посмотрите здесь. Сам я не пробовал так конфигурить.
https://disnetern.ru/nginx-server-configure-and-pr...