HTTP中的URL長度限制（資料整理）

2019-11-15 02:07:34

字體：大中小

供稿：網(wǎng)友

HTTP中的URL長度限制（資料整理）HTTP中的URL長度限制

首先，其實http 1.1 協(xié)議中對url的長度是不受限制的，協(xié)議原文：

The HTTP PRotocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource theyserve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

  Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxyimplementations might not properly support these lengths.

翻譯：

HTTP協(xié)議不對URI的長度作事先的限制，服務(wù)器必須能夠處理任何他們提供資源的URI，并且應(yīng)該能夠處理無限長度的URIs，這種無效長度的URL可能會在客戶端以基于GET方式的請求時產(chǎn)生。如果服務(wù)器不能處理太長的URI的時候，服務(wù)器應(yīng)該返回414狀態(tài)碼（此狀態(tài)碼代表Request-URI太長）。

注:服務(wù)器在依賴大于255字節(jié)的URI時應(yīng)謹(jǐn)慎，因為一些舊的客戶或代理實現(xiàn)可能不支持這些長度。

具體參見協(xié)議中的3.2.1

雖然協(xié)議中未明確對url進行長度限制，但在真正實現(xiàn)中，url的長度還是受到限制的，一是服務(wù)器端的限制，二就是游覽器端的限制。

一、服務(wù)器端

在服務(wù)器端，主要是apache，jboss和nginx等，我在網(wǎng)上找到的調(diào)節(jié)方法可以參加下文：關(guān)于http請求url長度以及請求消息體長度的研究（一）（服務(wù)器端）

1.1 nginx

由于現(xiàn)在項目中主要用到nginx，所以強調(diào)下它的設(shè)置參數(shù)：large_client_header_buffers

該參數(shù)對nginx服務(wù)器接受客戶端請求的頭信息時所分配的最大緩沖區(qū)的大小做了限制，也就是nginx服務(wù)器一次接受一個客戶端請求可就收的最大頭信息大小。這個頭不僅包含 request-line，還包括通用信息頭、請求頭域、響應(yīng)頭域的長度總和。這也相當(dāng)程度的限制了url的長度。

nginx服務(wù)器默認的限制是4K或者8K，這是根據(jù)服務(wù)器的硬件配置有關(guān)的，一般為內(nèi)存一頁的大小，目前大部分為4K，即4096字節(jié)。

二、游覽器端

游覽器的種類繁多，并且對URL的長度限制是有所差異的，具體如下：

游覽器	最大長度（字符數(shù)）	備注
Internet Explorer	2083	如果超過這個數(shù)字，提交按鈕沒有任何反應(yīng)
Firefox	65,536
Chrome	8182
Safari	80,000
Opera	190,000
curl（linux下指令）	8167

這些數(shù)據(jù)主要通過網(wǎng)上數(shù)據(jù)搜索而來，筆者還沒有親自驗證過。但都有限制是不爭的事實，大家在做開發(fā)時要特別注意。

我首先想到的就是去看HTTP 1.1 協(xié)議，看是不是有限制（這協(xié)議真是又臭又長.......）。驚奇的發(fā)現(xiàn)，原來協(xié)議對url是不做長度限制的。原話如下：

"The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengthsabove 255 bytes, because some older client or proxyimplementations might not properly support these lengths."

注:服務(wù)器在依賴大于255字節(jié)的URI時應(yīng)謹(jǐn)慎，因為一些舊的客戶或代理實現(xiàn)可能不支持這些長度。

所以從http標(biāo)準(zhǔn)協(xié)議上講沒有對url長度進行控制，header頭長度是否有限制有待進一步研究協(xié)議。對url以及header長度的限制主要取決于服務(wù)器以及客戶端的限制。

然后先從服務(wù)器端入手：

主要看了apache和nginx兩種服務(wù)器，其他的咱也不熟

在apache的官方文檔上找到這樣一個配置選項 LimitRequestLine

關(guān)于http請求url長度以及請求消息體長度的研究（一）（服務(wù)器端）（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline）

從定義來看，這個選項限制的并不是url的長度，也不是head頭的長度，而是是http請求中 request-line的長度（相關(guān)定義：http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1）。

即：Request-Line = Method SP Request-URI SP HTTP-Version CRLF 的長度。

但這很大程度上也就限制的GET、HEAD請求的參數(shù)長度，因為GET和HEAD請求是不會向服務(wù)器發(fā)送消息實體（message-body）的?？梢哉f這個限制就是限制了url的長度不能超過該設(shè)定的值，如果超過了，服務(wù)器會返回錯誤狀態(tài)碼 414（Request-URI Too Large）。

那么對于整個消息體，apache服務(wù)器有限制嗎？

接下來我有看了其他相關(guān)的參數(shù)，果然有：LimitRequestBody

關(guān)于http請求url長度以及請求消息體長度的研究（一）（服務(wù)器端）（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody）

這個參數(shù)限制了http請求可以被接受的最大消息大小，默認是無限大的，但是其實這個無限也是有限的，最大不能超過2G。

這就是apache服務(wù)器對http請求的相關(guān)的一些限制

對于nginx服務(wù)器，也有類似的參數(shù)

large_client_header_buffers

關(guān)于http請求url長度以及請求消息體長度的研究（一）（服務(wù)器端）

該參數(shù)對nginx服務(wù)器接受客戶端請求的頭信息時所分配的最大緩沖區(qū)的大小做了限制，也就是nginx服務(wù)器一次接受一個客戶端請求可就收的最大都信息大小。這個頭不僅包含 request-line，還包括通用信息頭、請求頭域、響應(yīng)頭域的長度總和。這也相當(dāng)程度的限制了url的長度。

nginx服務(wù)器默認的限制是4K或者8K，這是根據(jù)服務(wù)器的硬件配置有關(guān)的，一般為內(nèi)存一頁的大小，目前大部分為4K，即4096字節(jié)。

client_header_buffer_size

關(guān)于http請求url長度以及請求消息體長度的研究（一）（服務(wù)器端）（http://wiki.nginx.org/HttpCoreModule#client_header_buffer_size）