|
Когда я читал документацию по Google Chart API, во время подготовки посвященного ему поста, меня удивил немалый объем данных, который разработчики предлагают передавать через GET запросы. Причиной тому было непонятно откуда взявшееся убеждение в том, что максимальная длина URL, регламентированная стандартом HTTP, составляет 256 символов. В действительности это далеко не так (ложное воспоминание о числе 256 скорее всего было порождено SQL-типом VARCHAR или чем-то подробным). HTTP формально не лимитирует длину URL, но ограничение на нее накладывают реализации этого протокола.
Я нашел значения величин этих ограничений для популярных браузеров и HTTP-серверов в списке часто-задаваемых вопросов на сайте boutell.com. Далее по тексту — переведенный вариант выжимки из этой статьи, который я немного дополнил от себя.
Браузеры
Microsoft Internet Explorer: Начиная с четвертой версии браузера, максимальная длина воспринимаемого URL составляет 2,083 символов. При этом длина GET-запроса лимитирована 2,048 символа. На POST никаких ограничений, понятное дело, не накладывается.
Firefox: В старых версиях (1.5.x) было ограничение на 64 килобайта, но, вполне возможно, это был баг, который позже исправили. Теперь, по всей видимости, ограничения на длину URL снято вообще, либо оно существенно превышает «пределы разумного» (проверено, что Firefox может «съесть» URL длиной в 100,000 символов).
Safari: Лимита на длину URL нет так же, как и в Firefox. Автор FAQ успешно протестировал адрес длиной 80,000 символов.
Opera: По заявлению разработчиков, лимита нет. Успешно прошли тесты с 190,000 символами.
Серверы
Apache: Строго говоря, ограничение длины URL можно менять в конфигурации сервера параметрами LimitRequest*, поэтому все зависит от конкретного случая. Но существуют значения по-умолчанию, которые часто оставляют неизменными. Они лимитируют длину URL (точнее, любой строки HTTP-запроса) значением в 8 килобайт. В более ранних версиях Apache было 4 килобайта.
Microsoft Internet Information Server: По-умолчанию, длина URL ограничена пределом в 16 килобайт. При необходимости, значение можно увеличить. Немного странно, что сервер Microsoft не накладывает столь же жестких ограничений на этот параметр, как и браузер.
Perl HTTP::Daemon: 8,000 символов на длину URL и 16 килобайт для суммарного объема HTTP-заголовка. Лимит несложно снять, для чего потребуется откорректировать значения 16×1024 в файле Daemon.pm.
Общие рекомендации
Принимая во внимание приведенные сведения, конечно же не стоит использовать URL длиной более 2,000 символов. В противном случае такие ссылки не будут работать примерно у 60% пользователей интернет.
Чаще всего, этой величины будет вполне хватать, т.к. если речь идет о передаче большого объема информации с клиента на сервер, по многим причинам (для безопасности, например) рекомендуется отдавать предпочтение методу POST. То-есть делать так:
<form action="myscript.php" method="POST">
...
</form>
GET же предназначен для адресации страниц с динамическим контентом, чье содержимое не меняется при каждом повторном обращении. Самый распространенный тому пример — отчеты поисковых систем.
В общем случае, если данные не требуются для повторной генерации идентичной веб-страницы, такие данные не должны быть частью URL.
Когда необходимость в объемных URL все-таки присутствует, можно использовать разные алгоритмы кодирования для сокращения их длины. Один из примеров был приведен в уже упоминавшемся посте о Google Chart, на примере специального формата записи данных для построения диаграмм. В особо-тяжелых случаях можно сжимать данные gzip-ом с последующим кодированием в BASE64, но лучше, конечно, по возможности избегать таких вещей. Более красивым решением может быть использование базы данных для хранения на сервере параметров каждого запроса. В таком случае URL сможет содержать только короткий идентификатор необходимой записи.
Что произойдет на сервере при выходе длины запроса за дозволенный предел?
Будет выдано сообщение об ошибке с кодом 413 (Entity Too Large). Обрезания URL не произойдет по той причине, что результат изменения адреса может быть непредсказуем.
О том, как именно отреагирует в таком случае веб-приложение, однозначно ответить нельзя. В любом случае, всегда следует контролировать подобные ситуации.
По теме:
Написать комментарий
| 
# Лобач Олег: (19 декабря, 2007 @ 10:13)
Огромное спасибо за полезный пост!
У меня, кстати, тоже было стойкое убеждение, что длина URL ограничена 256 символами.
Еще раз спасибо за полезное исследование.
# admin: (19 декабря, 2007 @ 10:39)
Приятно слышать.
# grossu: (19 декабря, 2007 @ 10:45)
Прикольный url в 100000 символов. Примерно 25 страниц сплошного текста. IE как обычно порадовал.
# admin: (19 декабря, 2007 @ 10:53)
grossu: С другой стороны, благодаря фирменному отношению IE к стандартам, никто не станет совать 25 страниц в URL (:
# SHAman: (19 декабря, 2007 @ 16:07)
Я был уверен, что длина URL = 255 символов! Уверен был, потому что прочитал в книжке. Спасибо, что развеяли заблуждение мое.
Кстати, большой вопрос: стоит ли передавать много текста в URL… ИМХО, тех же 255(6) символов вполне достаточно.
# admin: (19 декабря, 2007 @ 17:54)
Вполне возможно, что причиной моих сомнений на тему 255/256 сиволов тоже была книга, но теперь уже сложно вспомнить, какая именно. Вероятно это было старым ограничением стандарта, или было как-то связано с особенностью обработки GET в PHP. Теперь уже не актуально.
Я уже упоминал о том, что обычно много текста не имеет смысла передавать через GET. Часто стоит отдавать предпочтение POST, безотносительно наличия ограничения длины URL. Например, для передачи данных из login-формы (чтобы не засветить в адресной строке пароль).
# SHAman: (20 декабря, 2007 @ 00:20)
Лично я использую ГЕТ только для передачи инфы о состоянии или положении. Грубо говоря, управляющие переменные для контроллера.
Если нужно отправлять данные, то ПОСТ.
# AM: (20 декабря, 2007 @ 13:35)
intersno… spasibo!
# Gene: (25 декабря, 2007 @ 03:41)
Спасибо, действительно полезно и познавательно! Я тоже читал в книге о 255 символах в УРЛ, видимо это было давно (ограничение).
Вообще конечно не стоит создавать лишнюю нагрузку на сервер в виде очень длинных УРЛ, особенно если к ним применяются достаточно сложные mod_rewrite регулярные выражения. Но иногда включать данные в УРЛ очень удобно.
# Gene: (25 декабря, 2007 @ 03:49)
Например, тогда когда, скажем пользователь просматривает каталог товаров. Параметров его выбора может быть очень много. И пользователь, сохранив УРЛ, всегда может снова получить тот же результат запроса, с учетом добавившихся позднее товаров, конечно, если таковые будут. А если бы мы хранили все в сессии, то это было бы невозможно. При этом ничего не мешает кроме этого и логиниться через форму, используя сессию и видеть, допустим, свою корзину покупателя. Даже возможно добавить cookie, чтобы логиниться автоматом.
# Тут Хумора.NET: (15 января, 2008 @ 11:26)
[...] has to offer. Each site is rated in order of uniqueness, visual quality, and overall presentation.Какой максимальной длины может быть URL? Всегда считал, что длина URL не должна превышать 32 [...]
# bappoy: (6 июня, 2008 @ 11:15)
Можно еще упомянуть про прокси-серверы, администраторы которых также могут накладывать свои ограничения. Например, в Squid параметр request_header_max_size по умолчанию равен 20 кб. В ISA тоже где-то в этом районе 16-20 кб.
# Станислав: (2 июля, 2008 @ 16:02)
IBM WebSphere Portal версии 6.0 автоматически генерирует URL длинной около 5500 байт
# Кир: (17 февраля, 2009 @ 12:22)
Есть смысыл передавать более 255 символов.
Пример: переводчик … нужно же форме передать текст? … а если у вас нет словаря и вы позаимствовали у гугла? … тогда стоит передать GET побольше … например небольшой текст письма.
# Holden: (3 марта, 2009 @ 15:43)
Некоторые серверы при оч. длинном запросе выдают ошибку
414 Request-URI Too Large.
# myvista: (26 марта, 2009 @ 18:13)
Это актуально становится когда данные пытаешься ajax-ом передавать с помощью метода GET
# Конторра: (14 мая, 2009 @ 00:03)
а для поисковиков какая рекомендуемая длина URL? кто-нибудь знает?
# Артур: (20 мая, 2009 @ 00:55)
Спасибо за полезную информацию. Редко читаю статьи полностью и до конца. Обычно нахожу то, что мне нужно. С этой статьей не так. Втянулся в чтение и даже прочел комментарии. Здоровья и желания писать так-же автору данной статьи.
От себя же хочу сказать, что необходимость передавать большие данные появляется при невозможности передать ее методом post. Например столкнулся при работе с json.
# Владимир: (27 мая, 2009 @ 06:53)
Вот блин! А я что один такой уникум, который во флеше картинки через запросі вінужден посылать? А какие- там у нас размеры? То-то же. Мне 64 кб на одном серваке ой как жить мешают, приходиться существенно сжимать жпегом, а о пнг уже и не мечтаю!!! Хотя на локальном сервере все норм!
# Zя: (24 июня, 2009 @ 10:22)
Владимир, ты не уникум, ты д****йоб.
Это надо делать через ПОСТ запрос.