問題起因
今天一位網友向我們反饋，用Chrome打開某些博客文章時，會出現"Bad Request - Request Too Long. HTTP Error 400. The size of the request headers is too long."的錯誤頁面：
用IE, Firefox都沒問題，唯有Chrome。
之前我們遇到過一次這樣的問題，當時以為是偶然因素引起的Chrome問題，于是在"%LOCALAPPDATA%\Google\"中將Chrome的配置文件重命名，讓Chrome重建配置，解決了問題。
今天，這個問題再次出現，就不能忽視了，必須找出問題的真正原因并找到解決辦法。
解決過程
開始我們推測，可能是某些原因造成Chrome發出的請求頭包含過多內容。查看Chrome請求的網址是正常的，也沒發現Request Header的異常。既然沒在Chrome找到問題的原因，那我們從服務端下手吧，請求長就長一點，只要能讓用戶看到正常的內容。
服務端IIS究竟在哪個地方返回這個錯誤的？開始以為是Request Filtering Module，調整了Request Limits設置不能解決問題，禁用Request Filtering Module也解決不了問題。
后來在IIS官方論壇的帖子HTTP 400. The size of the request headers is too long中得知，這個錯誤是Http.sys返回的，請求頭長度限制是由注冊表HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters中的兩個參數決定的：MaxFieldLength與MaxRequestBytes，缺省值都是16384字節，詳見Http.sys registry settings for IIS。
由于修改這兩個設置需要重啟IIS（net stop http, net start http, iisreset），并且只是表面上解決問題，所以我們沒有立即采取這個方法。又回過頭來在Chrome中查看請求頭，突然發現cookie的值好長。
進一步查看cookie：
很多cnzz_eid，這是cnzz統計代碼產生的，可是我們在博客中沒有使用cnzz。但是，有的用戶博客自己加了cnzz的統計代碼。我們檢查了一些會產生"Bad Request - Request Too Long"的頁面，的確有些加了cnzz的代碼。
我們手動在Chrome中刪除了一些帶有cnzz_eid的cookie，問題就解決了。
原來是cnzz惹的禍！
為什么在IE與Firefox中不會出現這個問題呢？
可能是IE與Firefox對于request header過長的請求會自動截斷；而Chrome對此置之不理。
小結
這篇文章分享的內容是：當IIS返回"Bad Request - Request Too Long. HTTP Error 400. The size of the request headers is too long."的錯誤時，說明客戶端發出的請求頭長度超出了Http.sys的限制，這個限制是由注冊表"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters"中的兩個參數MaxFieldLength與MaxRequestBytes決定的，默認值是16384字節。
