Какова максимально возможная длина строки запроса?


559

Это зависит от браузера? Кроме того, разные веб-стеки имеют разные ограничения на количество данных, которые они могут получить по запросу?


Вы также можете проверить это stackoverflow.com/questions/417142/…
Xinus

Это только для запросов GET! Максимальный размер POST-запросов (с или без multipart / form-data) здесь неизвестен!
Петер - Восстановить Монику

Ответы:


997

RFC 2616 (протокол передачи гипертекста - HTTP / 1.1) утверждает, что длина строки запроса не ограничена (раздел 3.2.1). RFC 3986 (Uniform Resource Identifier - URI) также утверждает, что ограничений нет, но указывает, что имя хоста ограничено 255 символами из-за ограничений DNS (раздел 2.3.3).

Хотя в спецификации не указана максимальная длина, практические ограничения накладываются веб-браузером и серверным программным обеспечением. Основываясь на исследованиях, которые, к сожалению, больше не доступны на своем первоначальном сайте (это приводит к теневому кажущемуся сайту ссуд), но которые все еще можно найти в интернет-архиве Boutell.com :

  • Microsoft Internet Explorer (браузер)
    Microsoft заявляет, что максимальная длина URL-адреса в Internet Explorer составляет 2083 символа, причем в части пути URL-адреса должно быть не более 2048 символов. Попытки использовать URL-адреса длиннее этого приводили к появлению четкого сообщения об ошибке в Internet Explorer.

  • Microsoft Edge (браузер)
    Ограничение составляет около 81578 символов. См. Ограничение длины URL в Microsoft Edge

  • Chrome
    Прекращает отображение URL-адреса после 64 тыс. Символов, но может содержать более 100 тыс. Символов. Никаких дальнейших испытаний сделано не было.

  • Firefox (Браузер)
    После 65 536 символов в строке адреса больше не отображается URL в Windows Firefox 1.5.x. Однако более длинные URL будут работать. Дальнейшее тестирование после 100 000 символов не проводилось.

  • Safari (Браузер)
    Будет работать не менее 80 000 символов. Тестирование не было опробовано.

  • Opera (Браузер)
    Будет работать не менее 190 000 символов. Прекращено тестирование после 190 000 символов. Opera 9 для Windows продолжала отображать полностью редактируемый, копируемый и вставляемый URL в адресной строке даже в 190 000 символов.

  • Apache (сервер)
    Ранние попытки измерить максимальную длину URL-адреса в веб-браузерах натолкнулись на ограничение длины URL-адреса сервера, равное приблизительно 4000 символов, после чего Apache выдает ошибку «413 Entity Too Large». Была использована текущая современная версия Apache, найденная в Red Hat Enterprise Linux 4. В официальной документации Apache упоминается ограничение в 8 192 байта для отдельного поля в запросе.

  • Microsoft Internet Information Server (сервер)
    Предел по умолчанию составляет 16 384 символа (да, веб-сервер Microsoft принимает более длинные URL-адреса, чем веб-браузер Microsoft). Это настраивается.

  • Perl HTTP :: Daemon (сервер)
    Работает до 8000 байт. Те, кто создает серверы веб-приложений с помощью модуля Perl HTTP :: Daemon, сталкиваются с ограничением в 16 384 байта на общий размер всех заголовков HTTP-запросов. Это не относится к данным форм POST-метода, загрузкам файлов и т. Д., Но включает URL-адрес. На практике это привело к ошибке 413, когда URL-адрес был значительно длиннее, чем 8000 символов. Это ограничение можно легко снять. Найдите все вхождения 16x1024 в Daemon.pm и замените их на большее значение. Конечно, это увеличивает вашу подверженность атакам типа «отказ в обслуживании».


8
Почему вы не говорите номер версии также вместо «Microsoft Internet Explorer (Browser)»?
ЖЖ

5
Похоже, что ограничение IIS по умолчанию для строки запроса значительно меньше 16 384 символов - здесь указано 2048: iis.net/configreference/system.webserver/security/…
JTech


Я думаю, что вы сделали тип, и ограничения DNS обсуждаются в разделе "3.2.2. Хост" RFC3986, а не 2.2.3. «Производители URI должны использовать имена, соответствующие синтаксису DNS, даже если использование DNS не является очевидным, и должны ограничивать эти имена длиной не более 255 символов».
Крэйг Хикс

Причины java.lang.IllegalArgumentException: Request header is too largeна сервере приложений весенней загрузки tomcat.
Парамвир Сингх Карвал

12

Хотя официально RFC 2616 официально не ограничивает ограничения, многие протоколы и рекомендации по безопасности утверждают, что для maxQueryStrings на сервере должно быть установлено максимальное ограничение в 1024 символа. В то время как для всего URL-адреса, включая строку запроса, должно быть не более 2048 персонажи. Это сделано для предотвращения уязвимости DDOS Slow HTTP Request на веб-сервере. Обычно это проявляется как уязвимость сканера веб-приложений Qualys и других сканеров безопасности.

Ниже приведен пример кода для серверов Windows IIS с Web.config:

<system.webServer>
<security>
    <requestFiltering>
        <requestLimits maxQueryString="1024" maxUrl="2048">
           <headerLimits>
              <add header="Content-type" sizeLimit="100" />
           </headerLimits>
        </requestLimits>
     </requestFiltering>
</security>
</system.webServer>

Это также будет работать на уровне сервера, используя machine.config.

Примечание. Ограничение строки запроса и длины URL-адреса может не полностью предотвратить DDOS-атаки с медленными HTTP-запросами, но это один из шагов, которые можно предпринять, чтобы предотвратить его.


2
И теперь у меня есть причина, по которой я могу сказать бэкэнд-инженерам, что мы не примем список из ста 36-символьных UUID в queryParams запроса GET. Спасибо!
Мордред

1

Различные веб-стеки поддерживают разные длины http-запросов. По своему опыту я знаю, что ранние стеки Safari поддерживали только 4000 символов и, следовательно, имели трудности с обработкой страниц ASP.net из-за состояния пользователя. Это даже для POST, так что вам придется проверить браузер и посмотреть, каков предел стека. Я думаю, что вы можете достичь предела даже в новых браузерах. Я не могу вспомнить, но один из них (я думаю, IE6) имел ограничение в 16 бит, 32 768 или что-то в этом роде.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.