首先，其實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長度以及請求消息體長度的相關限制，這些我都只是根據其官方文檔得出的結果，沒有經過實際測試
