ajax HTTP 标头对于浏览器来说会不会太大？

Can HTTP headers be too big for browsers?

提问by HoLyVieR

I am building an AJAX application that uses both HTTP Content and HTTP Header to send and receive data. Is there a point where the data received from the HTTP Header won't be read by the browser because it is too big ? If yes, what is the limit and is it the same behaviour in all the browser ?

我正在构建一个 AJAX 应用程序，它使用 HTTP 内容和 HTTP 标头来发送和接收数据。从 HTTP Header 接收到的数据是否有一点不会被浏览器读取，因为它太大了？如果是，限制是什么，它在所有浏览器中的行为是否相同？

I know that theoretically there is no limit to the size of HTTP headers, but in practicewhat is the point that past that, I could have problem under certain platform, browsers or with certain software installed on the client computer or machine. I am more looking into a guide-line for safe practice of using HTTP headers. In other word, up to what extend can HTTP headers be used for transmitting additional data without having potential problem coming into the line ?

我知道理论上对 HTTP 标头的大小没有限制，但实际上，在某些平台、浏览器或客户端计算机或机器上安装的某些软件下，我可能会遇到问题。我更多地寻找使用 HTTP 标头的安全实践的指南。换句话说，HTTP 标头最多可以用于传输附加数据，而不会出现潜在问题？

---

---

Thanks, for all the input about this question, it was very appreciated and interesting. Thomas answer got the bounty, but Jon Hanna's answerbrought up a very good point about the proxy.

谢谢，对于这个问题的所有投入，非常感谢和有趣。Thomas 的回答得到了赏金，但Jon Hanna 的回答提出了关于代理的一个很好的观点。

采纳答案by Jon Hanna

In practice, while there are rules prohibitting proxies from not passing certain headers (indeed, quite clear rules on which can be modified and even on how to inform a proxy on whether it can modify a new header added by a later standard), this only applies to "transparent" proxies, and not all proxies are transparent. In particular, some wipe headers they don't understand as a deliberate security practice.

在实践中，虽然有一些规则禁止代理不传递某些标头（实际上，非常明确的规则是关于哪些可以修改，甚至关于如何通知代理是否可以修改由后来的标准添加的新标头），这只是适用于“透明”代理，并非所有代理都是透明的。特别是，一些他们不理解为故意安全实践的擦除标头。

Also, in practice some do misbehave (though things are much better than they were).

此外，在实践中，有些人确实行为不端（尽管情况比以前好得多）。

So, beyond the obvious core headers, the amount of header information you can depend on being passed from server to client is zero.

因此，除了明显的核心标头之外，您可以依赖从服务器传递到客户端的标头信息量为零。

This is just one of the reasons why you should never depend on headers being used well (e.g., be prepared for the client to repeat a request for something it should have cached, or for the server to send the whole entity when you request a range), barring the obvious case of authentication headers (under the fail-to-secure principle).

这只是为什么你永远不应该依赖于头被很好地使用的原因之一（例如，准备好让客户端重复请求它应该缓存的东西，或者当你请求一个范围时让服务器发送整个实体)，除非出现明显的身份验证标头情况（在安全失败原则下）。

回答by Thomas

Short answers:

简短的答案：

Same behaviour: No

相同的行为：否

Lowest limit found in popular browsers:

流行浏览器中的最低限制：

• 10KB per header
• 256 KB for all headers in one response.

• 每个标头 10KB
• 一个响应中的所有标头为 256 KB。

Test results from MacBook running Mac OS X 10.6.4:

运行 Mac OS X 10.6.4 的 MacBook 的测试结果：

Biggest response successfully loaded, all data in one header:

最大的响应成功加载，所有数据在一个标题中：

• Opera 10: 150MB
• Safari 5: 20MB
• IE 6 via Wine: 10MB
• Chrome 5: 250KB
• Firefox 3.6: 10KB

• 歌剧 10：150MB
• Safari 5：20MB
• IE 6 通过 Wine：10MB
• 铬 5：250KB
• 火狐 3.6：10KB

NoteThose outrageous big headers in Opera, Safari and IE took minutes to load.

注意Opera、Safari 和 IE 中那些令人发指的大标题需要几分钟才能加载。

Note to Chrome:Actual limit seems to be 256KB for the whole HTTP header. Error message appears: "Error 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Unknown error."

Chrome 请注意：整个 HTTP 标头的实际限制似乎是 256KB。出现错误消息：“错误 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG)：未知错误。”

Note to Firefox:When sending data through multiple headers 100MB worked fine, just split up over 10'000 headers.

Firefox 注意：当通过多个标头发送数据时，100MB 工作正常，只需拆分 10'000 个标头即可。

My Conclusion: If you want to support all popular browsers 10KB per header seems to be the limit and 256KB for all headers together.

我的结论：如果你想支持所有流行的浏览器，每个标头 10KB 似乎是限制，所有标头加起来为 256KB。

My PHP Code used to generate those responses:

我的 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';

?>

回答by Sasha Chedygov

Two things.

两件事情。

First of all, why not just run a test that gives the browser progressively larger and larger headers and wait till it hits a number that doesn't work? Just run it once in each browser. That's the most surefire way to figure this out. Even if it's not entirely comprehensive, you at least have some practical numbers to go off of, and those numbers will likely cover a huge majority of your users.

首先，为什么不直接运行一个测试，让浏览器逐渐增大标头，然后等到它遇到一个不起作用的数字？只需在每个浏览器中运行一次。这是解决这个问题的最可靠方法。即使它并不完全全面，您至少也有一些实用的数字可供参考，而这些数字很可能涵盖了您的绝大多数用户。

Second, I agree with everyone saying that this is a bad idea. It should not be hard to find a different solution if you are really that concerned about hitting the limit. Even if you do test on every browser, there are still firewalls, etc to worry about, and there is absolutely no way you will be able to test every combination (and I'm almost positive that no one else has done this before you). You will not be able to get a hard limit for every case.

其次，我同意大家说这是一个坏主意。如果您真的很担心达到极限，那么找到不同的解决方案应该不难。即使您在每个浏览器上都进行了测试，仍然需要担心防火墙等问题，而且您绝对无法测试每个组合（我几乎可以肯定，在您之前没有其他人这样做过） . 您将无法对每种情况都设置硬性限制。

Though in theory, this should all work out fine, there might later be that one edge case that bites you in the butt if you decide to do this.

虽然从理论上讲，这应该一切正常，但如果您决定这样做，以后可能会有一个边缘情况让您大吃一惊。

TL;DR: This is a bad idea.Save yourself the trouble and find a real solution instead of a workaround.

TL;DR：这是个坏主意。省去麻烦并找到真正的解决方案而不是解决方法。

---

---

Edit:Since you mention that the requests can come from several types of sources, why not just specify the source in the request header and have the data contained entirely in the body? Have some kind of Sourceor ClientTypefield in the header that specifies where the request is coming from. If it's coming from a browser, include the HTML in the body; if it's coming from a PHP application, put some PHP-specific stuff in there; etc etc. If the field is empty, don't add any extra data at all.

编辑：既然您提到请求可以来自多种类型的来源，为什么不在请求标头中指定来源并将数据完全包含在正文中？在标头中有某种Source或ClientType字段，用于指定请求的来源。如果来自浏览器，则在正文中包含 HTML；如果它来自 PHP 应用程序，则在其中放入一些特定于 PHP 的内容；等等等等。如果该字段为空，则根本不要添加任何额外数据。

回答by Karman Kertesz

The RFC for HTTP/1.1 clearly does not limit the length of the headers or the body.

HTTP/1.1 的 RFC 显然没有限制标头或正文的长度。

According to this page modern browsers (Firefox, Safari, Opera), with the exception of IE can handle verylong URIs: https://web.archive.org/web/20191019132547/https://boutell.com/newfaq/misc/urllength.html. I know it is different from receiving headers, but at least shows that they can create and send huge HTTP requests (possibly unlimited length).

根据此页面现代浏览器（Firefox、Safari、Opera），IE 除外可以处理很长的 URI：https://web.archive.org/web/20191019132547/https: //boutell.com/newfaq/misc /urllength.html。我知道它与接收标头不同，但至少表明它们可以创建和发送巨大的 HTTP 请求（可能是无限长度）。

If there's any limit in the browsers it would be something like the size of the available memory or limit of a variable type, etc.

如果浏览器有任何限制，则可能是可用内存的大小或变量类型的限制等。

回答by Kranu

Theoretically, there's no limit to the amount of data that can be sent in the browser. It's almost like saying there's a limit to the amount of content that can be in the body of a web page.

理论上，浏览器中可以发送的数据量没有限制。这几乎就像在说网页正文中可以包含的内容量是有限的。

If possible, try to transmit the data through the body of the document. To be on the safe side, consider splitting the data up, so that there are multiple passes for loading.

如果可能，请尝试通过文档正文传输数据。为了安全起见，请考虑将数据拆分，以便进行多次加载。