關於HTTP的GET請求引數長度限制問題和我對中國式教育的吐槽
隱隱約約記得，http的get請求的引數長度是有限制的，所以當從客戶端向服務端傳送資料時，如果資料量太大，那麼就不要用get方法，而要用post方法。
我相信，很多人同我一樣，對這個問題的認識僅僅停留在上一段文字所描述的水平內，含糊不清，似懂非懂，好像知道，但是又拿不準。我們喜歡批評中國的教育，常常列舉出各種弊病，這裡，我很想說，我們的教育，很失敗的一個地方就是，培養了數以百萬計的大學生，可數以百萬計的大學生卻很少有人具備科學精神。前陣子，看到一個新聞，一個老師帶著學生們做實驗，實驗的內容就是驗證溫水到底能不能煮青蛙。一直以來，我們看到的各種心靈雞湯都告訴我們，用溫水煮青蛙，青蛙不會跳走，這故事告訴我們，不要安於現狀，說起來真的好哲理啊，但是青蛙真的有那麼傻麼？這位老師帶著這樣的懷疑和學生們一起做實驗，而實驗的結果就是，水熱了，青蛙就TM的跳出來了。這麼多年了，對這個故事深信不疑，被這個故事少說騙了十年了，知道真相的我當時眼淚掉下來了。
憤怒羞愧之餘，我也反思，這十年來， 自己為啥就沒有懷疑過呢，可能有過懷疑，但是為啥不做一個實驗證實一下呢？因為作為中國式教育下的學生，我們只會被動的接受知識，從沒有懷疑的膽量和權力。有些事情，我至今仍耿耿於懷，中學時，語文卷子上必有一篇文章讓你閱讀，然後出各種各樣的題，這些題中，必然有一道題目，讓你分析文章的中心思想，或是對某一段進行分析以闡述作者當時的所思所想。我的個天啊，用現在的話來說，太坑爹了，因為你的答案必須和老師提供的標準答案一致。而我最耿耿於懷的是，那些所謂的標準答案太他媽的扯淡了，我時常在想，作者真的是這麼想的麼?作者寫這篇文章的時候真的像老師所分析的那樣，設計了各種巧妙的情節，運用各種巧妙的手法來表達所思所想麼？以我自己寫作文的經歷來看，你有感覺的時候，哪他媽的想那麼多啊，基本上是想到哪就寫到哪，文章都是一氣呵成的，根本沒有那麼多事後諸葛亮式的分析與考慮，一次課間休息時，不知道哪根神經搭錯線了，突然就想寫點東西，於是伏案10分鐘，那可真是文思泉湧，那可真是倚馬可待，不吹牛，10分鐘的文章在課堂上被當做範文朗讀。但是不管你多麼懷疑，多麼不情願，你都必須按照老師教給你的套路去分析文章，因為只有這樣，你才能接近那個恐怕連作者自己都不未必認同的答案。
填鴨式的教育，必然導致學生缺少實證精神，缺少科學的態度。你去書店裡逛一逛，重點去計算機技術區域，同樣一個領域，你找一本中國人寫的，再找一本外國人寫的，你看過就知道了，差距究竟在哪裡。差距根本不在技術，要說技術有差距，是有的，但更大的差距在於老外的書大多有著嚴禁認真負責的態度，他們寫書更像是在做學問，而你讀中國作者寫的書，你明顯能感覺到他在糊弄你，正因如此，才有各種各樣的30天學會什麼什麼，30天精通什麼什麼，你這是在騙人，很多程式猿，終其一生都是個半吊子，更別說30天了。這裡，我極力向大家建議，今後買書，一定要買圖靈教育系列的，一分錢，一分貨，永恆的真理。
其實，我原本是要寫一篇技術貼的，但是，從第二段開始，文思泉湧了一下，就拐到了對中國式教育的吐槽，現在，還是言歸正傳，說說HTTP的GET請求引數的長度限制問題。
首先，我們要明確一點，HTTP協議裡，並沒有對GET請求的引數的長度做出任何的限制，事實上，HTTP協議對RUI的長度沒有做任何的限制，協議只是規定了，如果URI太長了而伺服器又處理不了的話，應該返回一個414狀態碼，以下是HTTP協議的原文：
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.
上面這段出自1999年釋出的RFC2616 3.2.1章節。2014年，IETF對http協議進行了更新，將RFC2616拆分為6個單獨的協議說明，為了拿出更加確鑿的證據，我把這六個協議也翻了出來，在RFC 7230的3.1.1章節中也有類似的表述，原文如下：
HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5. A server that receives a method longer than any that it implements SHOULD respond with a 501(Not Implemented) status code. A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of [RFC7231]).
新舊兩個版本的HTTP協議皆給出了相同的解釋，這裡附上兩個協議說明的地址
RFC2616 RFC7230
那麼為什麼，許多人和我一樣，留下了HTTP的get請求的引數長度受限制的印象呢？原來是伺服器和瀏覽器對URL長度做了限制。
以Tomcat為例，在server.xml中可以配置很多引數，其中有一個引數名為maxHttpHeaderSize，這個引數對請求頭和響應頭的大小做了限制，其實，也就間接限制了URL的大小。我手裡的tomcat版本是7.0.55，server.xml在conf目錄下，server.xml中並沒有這個引數的配置，我想，可能是需要使用者自己進行配置而不是該版本釋出的時候就配置好了。對於這個引數究竟是否起作用以及究竟會限制多長的URL，我並沒有實際進行測試驗證，以上僅僅是我查閱資料所得。
不同廠商的瀏覽器對URL的長度做了限制，我看了很多帖子，都說IE對URL長度的限制是2083個字元，相比於大多數程式猿已經是一種進步了，但還是不夠準確，因為對於get請求，能夠使用的URL長度是2048，也就是說IE的get請求最多允許傳送2048個字元，但真實的情況真的是這樣麼？
作為程式猿，一定要有博覽群書的大志向，只有這樣，才不會被技術的浪潮拍死在沙灘上，作為攻城獅，還要有嚴禁的治學態度，不人云亦云，拿不準的時候就寫程式去驗證，只有這樣，才不會被不經驗證的善意轉帖忽悠，這不是在好為人師，而是對我個人的一個警示，技術再糙，也要有攻城獅的節操。近來一段時間，看了很多不負責任的轉帖，也為很多細心權威的帖子所折服，至此立志，從今以後，儘量寫原創帖，若轉載，事先必驗證其帖子內容的有效性。
最後，我來驗證，IE瀏覽器的get請求的URL長度到底限制到多少，咱們先來一個服務端（node.js）：
/**
- Created by kwsy on 2015/8/15. */ var http = require(‘http’) var server = http.createServer(function(req,res){ console.log(req.url); console.log(req.url.length); }).listen(1337);
server.on(‘connection’,function(socket){ console.log(‘客戶端建立連線’); }) 然後，來一段URL
受到編輯器限制，上面的url顯示的有問題，sheng?和test應該是連在一起的，一共是2083個字元，複製到IE瀏覽器的位址列裡點選回車 下圖是實際執行的結果
伺服器收到的url長度是2026，也就是說，有一部分被截掉了，前面的“http://localhost:1337” 長度是21，
加在一起是2047，我使用的IE 11，經試驗，
IE 11對get請求的url長度的限制是2047個字元，而不是網上帖子所說的2048個字元。
為這一個字元寫這麼一篇帖子值得麼？值！用這篇帖子警示自己，任何時刻，做任何事，都要有嚴禁治學的態度