HTTP中的URL長度限制（資料整理），url長度_PHP教程

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

HTTP中的URL長度限制

首先，其實http 1.1 協議中對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 lengths above 255 bytes, because some older client or proxyimplementations might not properly support these lengths.

翻譯：

HTTP協議不對URI的長度作事先的限制，伺服器必須能夠處理任何他們提供資源的URI，並且應該能夠處理無限長度的URIs，這種無效長度的URL可能會在用戶端以基於GET方式的請求時產生。如果伺服器不能處理太長的URI的時候，伺服器應該返回414狀態代碼（此狀態代碼代表Request-URI太長）。

注:伺服器在依賴大於255位元組的URI時應謹慎，因為一些舊的客戶或代理實現可能不支援這些長度。

具體參見協議 中的3.2.1

雖然協議中未明確對url進行長度限制，但在真正實現中，url的長度還是受到限制的，一是伺服器端的限制，二就是遊覽器端的限制。

一、伺服器端

在伺服器端，主要是apache，jboss和nginx等，我在網上找到的調節方法可以參加下文：關於http請求url長度以及請求訊息體長度的研究（一）（伺服器端）

1.1 nginx

由於現在項目中主要用到nginx，所以強調下它的設定參數：large_client_header_buffers

該參數對nginx伺服器接受用戶端請求的頭資訊時所分配的最大緩衝區的大小做了限制，也就是nginx伺服器一次接受一個用戶端請求可就收的最大頭資訊大小。這個頭不僅包含 request-line，還包括通用資訊頭、要求標頭域、回應標頭域的長度總和。這也相當程度的限制了url的長度。

nginx伺服器預設的限制是4K或者8K，這是根據伺服器的硬體設定有關的，一般為記憶體一頁的大小，目前大部分為4K，即4096位元組。

二、遊覽器端

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

遊覽器	最大長度（字元數）	備忘
Internet Explorer	2083	如果超過這個數字，提交按鈕沒有任何反應
Firefox	65,536
chrome	8182
Safari	80,000
Opera	190,000
curl（linux下指令）	8167

這些資料主要通過網上資料搜尋而來，筆者還沒有親自驗證過。但都有限制是不爭的事實，大家在做開發時要特別注意。

我首先想到的就是去看HTTP 1.1 協議，看是不是有限制（這協議真是又臭又長.......）。驚奇的發現，原來協議對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 lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths."

HTTP協議不對URI的長度作事先的限制，伺服器必須能夠處理任何他們提供資源的URI，並且應該能夠處理無限長度的URIs，這種無效長度的URL可能會在用戶端以基於GET方式的請求時產生。如果伺服器不能處理太長的URI的時候，伺服器應該返回414狀態代碼（此狀態代碼代表Request-URI太長）。

注:伺服器在依賴大於255位元組的URI時應謹慎，因為一些舊的客戶或代理實現可能不支援這些長度。

所以從http標準協議上講沒有對url長度進行控制，header頭長度是否有限制有待進一步研究協議。對url以及header長度的限制主要取決於伺服器以及用戶端的限制。

然後先從伺服器端入手：

主要看了apache和nginx兩種伺服器，其他的咱也不熟

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

（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline）

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

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

但這很大程度上也就限制的GET、HEAD請求的參數長度，因為GET和HEAD請求是不會向伺服器發送訊息實體（message-body）的。可以說這個限制就是限制了url的長度不能超過該設定的值，如果超過了，伺服器會返回錯誤狀態代碼 414（Request-URI Too Large）。

那麼對於整個訊息體，apache伺服器有限制嗎？

接下來我有看了其他相關的參數，果然有 ：LimitRequestBody

（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody）

這個參數限制了http請求可以被接受的最大訊息大小，預設是無限大的，但是其實這個無限也是有限的，最大不能超過2G。

這就是apache伺服器對http請求的相關的一些限制

對於nginx伺服器，也有類似的參數

large_client_header_buffers

該參數對nginx伺服器接受用戶端請求的頭資訊時所分配的最大緩衝區的大小做了限制，也就是nginx伺服器一次接受一個用戶端請求可就收的最大都資訊大小。這個頭不僅包含 request-line，還包括通用資訊頭、要求標頭域、回應標頭域的長度總和。這也相當程度的限制了url的長度。

nginx伺服器預設的限制是4K或者8K，這是根據伺服器的硬體設定有關的，一般為記憶體一頁的大小，目前大部分為4K，即4096位元組。

client_header_buffer_size

（http://wiki.nginx.org/HttpCoreModule#client_header_buffer_size）

該參數對發自用戶端的http頭資訊的大小進行了限制，這個值和large_client_header_buffers同時限制了http要求標頭的大小，超過其中一個值則伺服器會返回錯誤狀態代碼 414（Request-URI Too Large）。

該參數的預設值為1K

client_max_body_size

該參數對發自用戶端的http請求的訊息實體大小進行了限制，如果超過該值，則會伺服器會返回錯誤狀態代碼 413（Request Entity Too Large）。此參數預設值為1MB，相當於是限制了post方式提交內容的最大限制

以上便是伺服器端對http請求url長度以及請求訊息體長度的相關限制，這些我都只是根據其官方文檔得出的結果，沒有經過實際測試

http://www.bkjia.com/PHPjc/973824.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/973824.htmlTechArticleHTTP中的URL長度限制（資料整理），url長度 HTTP中的URL長度限制 首先，其實http 1.1 協議中對url的長度是不受限制的，協議原文： The HTTP prot...

