Могут ли заголовки HTTP быть слишком большими для браузеров?

Я создаю приложение AJAX, которое использует как HTTP-контент, так и HTTP-заголовок для отправки и получения данных. Есть ли точка, в которой данные, полученные от заголовка HTTP, не будут считаться браузером, потому что они слишком большие? Если да, каков предел и это одно и то же поведение во всем браузере?

Я знаю, что теоретически нет ограничений на размер заголовков HTTP, но в практике, что было в прошлом, я мог бы иметь проблемы с определенной платформой, браузерами или с установленным программным обеспечением на клиентском компьютере или машине. Я больше изучаю руководство для безопасной практики использования HTTP-заголовков. Другими словами, до какой степени могут использоваться HTTP-заголовки для передачи дополнительных данных без возникновения потенциальной проблемы в строке?

Спасибо, что все материалы по этому вопросу были очень оценены и интересны. Томас ответ получил щедрость, но ответ Джона Ханны поднял очень хороший момент про прокси.

ОТВЕТЫ

Ответ 1

На практике существуют правила, запрещающие прокси-серверам не передавать определенные заголовки (действительно, достаточно четкие правила, по которым можно изменить, и даже о том, как информировать прокси о том, может ли он модифицировать новый заголовок, добавленный более поздним стандартом), это относится только к "прозрачным" прокси, и не все прокси прозрачны. В частности, некоторые протрите заголовки, которые они не понимают, как преднамеренную практику безопасности.

Кроме того, на практике некоторые из них плохо себя ведут (хотя вещи намного лучше, чем они были).

Таким образом, за пределами очевидных заголовков ядра количество информации заголовка, которое вы можете зависеть от передачи от сервера к клиенту, равно нулю.

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

Ответ 2

Краткие ответы:

То же поведение: Нет

Самый низкий предел найден в популярных браузерах:

  • 10 КБ на заголовок
  • 256 КБ для всех заголовков в одном ответе.

Результаты тестов MacBook с Mac OS X 10.6.4:

Самый большой ответ успешно загружен, все данные в одном заголовке:

  • Opera 10: 150MB
  • Safari 5: 20MB
  • IE 6 через Wine: 10 МБ
  • Chrome 5: 250KB
  • Firefox 3.6: 10KB

Примечание Эти возмутительные большие заголовки в Opera, Safari и IE заняли минуты, чтобы загрузить.

Примечание для Chrome: Фактический предел, по-видимому, составляет 256 Кбайт для всего HTTP-заголовка. Появится сообщение об ошибке: "Ошибка 325 (net:: ERR_RESPONSE_HEADERS_TOO_BIG): Неизвестная ошибка."

Примечание для Firefox: При отправке данных через несколько заголовков 100 МБ работало нормально, просто разделилось на 10 000 заголовков.

Мой вывод: Если вы хотите поддерживать все популярные браузеры, то 10 Кбайт на каждый заголовок, кажется, предел и 256 КБ для всех заголовков.

Мой PHP-код, используемый для генерации этих ответов:

<?php

ini_set('memory_limit', '1024M');
set_time_limit(90);
$header = "";

$bytes = 256000;

for($i=0;$i<$bytes;$i++) {
    $header .= "1";
}

header("MyData: ".$header);
/* Firfox multiple headers
for($i=1;$i<1000;$i++) {
    header("MyData".$i.": ".$header);
}*/

echo "Length of header: ".($bytes / 1024).' kilobytes';

?>

Ответ 3

Две вещи.

Прежде всего, почему бы просто не запустить тест, который дает браузеру все больше и больше заголовков и ждать, пока он не достигнет числа, которое не работает? Просто запустите его один раз в каждом браузере. Это самый верный способ понять это. Даже если он не является полностью исчерпывающим, у вас есть хотя бы некоторые практические цифры, и эти цифры, вероятно, охватывают огромное количество ваших пользователей.

Во-вторых, я согласен с тем, что все говорят, что это плохая идея. Не должно быть сложно найти другое решение, если вы действительно заинтересованы в достижении предела. Даже если вы проводите тестирование в каждом браузере, все еще есть брандмауэры и т.д., И вы абсолютно не сможете проверить каждую комбинацию (и я почти уверен, что никто другой не сделал этого до вас), Вы не сможете получить жесткий предел для каждого случая.

Хотя теоретически все должно быть хорошо, тогда может быть один случай с краем, который укусит вас в прикладе, если вы решите это сделать.

TL; DR: Это плохая идея. Сохраните проблему и найдите реальное решение вместо обходного пути.

Изменить:. Поскольку вы упоминаете, что запросы могут поступать из нескольких типов источников, почему бы просто не указать источник в заголовке запроса и не содержать ли данные целиком в теле? Введите заголовок Source или ClientType в заголовке, который указывает, откуда идет запрос. Если он поступает из браузера, включите HTML в тело; если он поступает из PHP-приложения, добавьте некоторые PHP-специфические вещи; и т.д. Если поле пустое, не добавляйте никаких дополнительных данных.

Ответ 4

RFC для HTTP/1.1 явно не ограничивает длину заголовков или тела.

В соответствии с этой страницей современные браузеры (Firefox, Safari, Opera), за исключением IE, могут обрабатывать очень длинные URI: http://www.boutell.com/newfaq/misc/urllength.html. Я знаю, что он отличается от приема заголовков, но по крайней мере показывает, что они могут создавать и отправлять огромные HTTP-запросы (возможно, неограниченную длину).

Если в браузерах есть какой-либо предел, это будет похоже на размер доступной памяти или ограничение типа переменной и т.д.

Ответ 5

Теоретически, нет ограничений на количество данных, которые могут быть отправлены в браузере. Это почти похоже на то, что существует ограничение на количество контента, которое может находиться в теле веб-страницы.

Если возможно, попробуйте передать данные через тело документа. Чтобы быть в безопасности, рассмотрите разделение данных вверх, чтобы было несколько проходов для загрузки.