到新公司處理的第乙個線上問題是某個商品頁，在某個人機器上訪問失敗，nginx返回400錯誤，但其它人機器上沒有問題，即使用虛擬機器重建了出問題機器的軟硬體環境也不會出問題。
經過對出問題機器的http請求進行抓包，發現url超長，cookie也很大，然後問題就很清楚了，因為大部分人用的是ie瀏覽器，ie瀏覽器限制了url長度，做了自動截斷處理，所以總的http header不會超出nginx的限制，可以正常返回，而使用同樣瀏覽器，不限制url長度，但cookie長度較短，沒超過nginx的header緩衝區限制，也不會造成400錯誤。
解決辦法就是修改nginx、tomcat等使用到的應用伺服器，讓他們支援更大的header緩衝區。當然從相容性等方面的考慮，根本解決辦法是不要通過get方式傳遞超長的引數。
***************===下邊列出了各個瀏覽器的限制和處理辦法*************************
附：各瀏覽器對url的長度限制(單位：字元個數）
ie : 2803
firefox:65536
chrome:8182
safari:80000
opera:190000
附：各瀏覽器允許域下的最大cookie數目
ie :原先為20個，後來公升級為50個
firefox: 50個
opera:30個
chrome:180個
safari:無限制
附：瀏覽器所允許的每個cookie的最大長度
firefox和safari:4079位元組
opera:4096位元組
ie:4095位元組
附：各應用伺服器設定header頭部的引數
nginx：
client_header_buffer_size和
解決get提交資料量太大的問題
由於引數中是base64編碼後的資料，比較大，導致get請求失敗，提示資料太大。get最大是256b，post是2m。解決方式 使用偽post方式 上傳方法 function picupload var ocrimagesrc document.queryselector ocr img child...
GET請求的長度限制
最近在生產環境為上游服務提供了乙個批量介面 dubbo介面 沒有做長度的限制，造成我呼叫下游的http請求 get請求 時由於長度 大概9000 個字元 超過了限制，造成直接返回400 bad request，影響了上游服務的使用，特查閱了相關資料，確定了nginx和apache等元件都是由相應的限...
請求大資料量介面時手動分頁
前段時間做專案遇到這麼種情況，需要呼叫乙個批量查詢介面，get請求的 比如根據使用者id批量查詢使用者資訊的，介面提供方提供的就是get請求的，然而我們一次要查詢幾萬個使用者，這樣請求的結果就是介面直接掛掉，因為get請求沒法傳遞那麼多資料，最後的解決方案是人為地進行分頁 private listq...