URL усекается до 255 символов - PullRequest
5 голосов
/ 04 марта 2010

У меня есть виджет JavaScript, который связывается с моим приложением Rails путем создания тегов в DOM. Время от времени я вижу некорректный запрос в журналах сервера, где URL усекается до 255 символов:

http://myapplication.example/mycontroller/1/myaction?hostname=www.mycustomer.example&request[param_a]=3&request[param_b]=1&request[param_c]=0&request[param_d]=0&request[param_e]=3&request[param_f]=1&request[param_g]=4&request[param_h]=0&request[param_i]=5&request

Из Google и Stackoverflow ( Какая максимальная длина URL-адреса в разных браузерах? ), похоже, 255 символов не является допустимым пределом для URL-адресов.

Вот что я знаю:

  • Это спорадическая проблема, она не возникает на ВСЕХ запросах
  • URL-адрес усекается до 255 символов, когда это происходит
  • Когда эта ошибка возникает, пользовательский агент не записывается в обратном следе

Вот что я НЕ знаю:

  • В каких типах браузеров возникает эта ошибка? Возможно, какой-нибудь мобильный браузер ...

Каков наилучший способ устранения этой проблемы?

Ответы [ 3 ]

3 голосов
/ 04 марта 2010

Лучший способ решить корневую причину - это не сделать GET, а запрос POST.

AFAIK не имеет установленных ограничений на длину строки QueryString, поэтому реальный предел повсюду. Я знаю, что 4000 - это ограничение для некоторых веб-серверов (не помню, был ли это IIS или Apache и можно ли его изменить), но вполне возможно, что в некоторых браузерах ограничения намного меньше. Тот факт, что вы не получаете агента пользователя, может подчеркнуть, что это мобильный браузер, сканер или другое приложение, а не настоящий браузер.

POST-запросы немного сложнее, но они могут нести гораздо большую «полезную нагрузку» и могут быть настроены на стороне сервера.

2 голосов
/ 04 марта 2010

Я не уверен, почему это может произойти, RFC 2068 заявляет:

Серверы должны быть осторожны в зависимости от длины URI выше 255 байт, потому что некоторые старые реализации клиента или прокси могут не поддерживать должным образом эти длины.

Возможно, сервер неправильно обрабатывает длинные параметры GET или старые браузеры (возможно, IE6) усекают параметры перед отправкой в ​​надежде избежать неудачных запросов со стороны сервера.

Однако нет ограничений на длину запросов POST в любом браузере или сервере (о которых я знаю), поэтому это, вероятно, гарантированное рабочее решение.

Изменить: Эта ссылка гласит, что некоторые браузеры накладывают ограничения на длину строки запроса, однако все они кажутся довольно длинными. Возможно, мобильные браузеры ограничивают длину ~ 255 для экономии памяти, так как она в более ограниченном количестве.

0 голосов
/ 03 апреля 2012

Я видел это в моих журналах доступа. Есть несколько очень специфических IP-адресов, которые генерируют усеченные запросы. Просмотр всего трафика с этих IP-адресов показывает, что существуют также необрезанные запросы, содержащие строки пользовательских агентов. Некоторые из них содержат несколько строк пользовательских агентов (хотя я не видел более двух уникальных версий - Safari 5.0.5 / Mac 10.6.8 и IE 9.0 / NT 6.1), которые появляются в течение нескольких минут. Кроме того, во всех случаях, кроме 2, я вижу хороший запрос, за которым следует неправильный запрос примерно через 50 мс, где неправильный запрос идентичен хорошему запросу, но урезан до 255 байт. Оставшиеся 2 случая имеют плохой запрос перед хорошим запросом. Один из IP-адресов от AT & T Worldnet предполагает, что это может быть мобильный шлюз, но другие, похоже, были интернет-провайдерами, университетами или корпорациями.

Я пока не знаю, что могу из этого сказать. Крайне маловероятно, что Safari 5 и IE 9 появятся с одного IP-адреса. Три возможности - это виртуальная машина Windows на Mac OSX, IP-адрес - это шлюз, и два разных пользователя отправляли запросы через него или кто-то связывался со мной. Хотя кажется странным, что через шлюз будет проходить только два пользователя, а демографический посетитель этого конкретного сайта вряд ли будет использовать виртуальные машины (хотя это и невозможно), по крайней мере, для этой конкретной задачи.

Тот факт, что усеченные запросы сразу же следуют за не усеченными, вероятно, предполагает что-то, но я не знаю, что это такое. Может ли это быть плагин, воспроизводящий запрос, или NAT, воспроизводящий запрос? Прозрачный прокси?

...