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

Question

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

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

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

Answer 1

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

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

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

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

Результаты тестирования MacBook под управлением Mac OS X 10.6.4:

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

• Опера 10: 150 МБ
• Safari 5: 20 МБ
• IE 6 через Wine: 10MB
• Chrome 5: 250 КБ
• Firefox 3.6: 10 КБ

Примечание Эти возмутительные большие заголовки в 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';

?>

Answer 2

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

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

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

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

Answer 3

Две вещи.

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

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

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

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

---

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

Answer 4

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

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

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

Answer 5

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

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