分析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 proxy implementations might not properly support these lengths."
HTTP協議不對URI的長度作事先的限制，伺服器必須能夠處理任何他們提供資源的URI，並且應該能夠處理無限長度的URIs，這種無效長度的URL可能會在客戶端以基於GET方式的請求時產生。如果伺服器不能處理太長的URI的時候，伺服器應該返回
注:伺服器在依賴大於255位元組的URI時應謹慎，因為一些舊的客戶或代理實現可能不支援這些長度。
所以從http標準協議上講沒有對url長度進行控制，header頭長度是否有限制有待進一步研究協議。對url以及header長度的限制主要取決於伺服器以及客戶端的限制。
然後先從伺服器端入手：
主要看了apache和nginx兩種伺服器，其他的咱也不熟
在apache的官方文件上找到這樣一個配置選項 LimitRequestLine
（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline
即：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請求可以被接受的最大訊息大小，預設是無限大的，但是其實這個無限也是有限的，最大不能超過2G。
這就是apache伺服器對http請求的相關的一些限制
對於nginx伺服器，也有類似的引數
large_client_header_buffers
該引數對nginx伺服器接受客戶端請求的頭資訊時所分配的最大緩衝區的大小做了限制，也就是nginx伺服器一次接受一個客戶端請求可就收的最大都資訊大小。這個頭不僅包含 request-line，還包括通用資訊頭、請求頭域、響應頭域的長度總和。這也相當程度的限制了url的長度。
nginx伺服器預設的限制是4K或者8K，這是根據伺服器的硬體配置有關的，一般為記憶體一頁的大小，目前大部分為4K，即4096位元組。
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長度以及請求訊息體長度的相關限制，這些我都只是根據其官方文件得出的結果，沒有經過實際測試