問題起因

今天一位網(wǎng)友向我們反饋，用Chrome打開某些博客文章時(shí)，會(huì)出現(xiàn)"Bad Request - Request Too Long. HTTP Error 400. The size of the request headers is too long."的錯(cuò)誤頁(yè)面：

用IE, Firefox都沒問題，唯有Chrome。

之前我們遇到過一次這樣的問題，當(dāng)時(shí)以為是偶然因素引起的Chrome問題，于是在"%LOCALAPPDATA%\Google\&;中將Chrome的配置文件重命名，讓Chrome重建配置，解決了問題。

今天，這個(gè)問題再次出現(xiàn)，就不能忽視了，必須找出問題的真正原因并找到解決辦法。

解決過程

開始我們推測(cè)，可能是某些原因造成Chrome發(fā)出的請(qǐng)求頭包含過多內(nèi)容。查看Chrome請(qǐng)求的網(wǎng)址是正常的，也沒發(fā)現(xiàn)Request Header的異常。既然沒在Chrome找到問題的原因，那我們從服務(wù)端下手吧，請(qǐng)求長(zhǎng)就長(zhǎng)一點(diǎn)，只要能讓用戶看到正常的內(nèi)容。

服務(wù)端IIS究竟在哪個(gè)地方返回這個(gè)錯(cuò)誤的？開始以為是Request Filtering Module，調(diào)整了Request Limits設(shè)置不能解決問題，禁用Request Filtering Module也解決不了問題。

后來在IIS官方論壇的帖子HTTP 400. The size of the request headers is too long中得知，這個(gè)錯(cuò)誤是Http.sys返回的，請(qǐng)求頭長(zhǎng)度限制是由注冊(cè)表HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters中的兩個(gè)參數(shù)決定的：MaxFieldLength與MaxRequestBytes，缺省值都是16384字節(jié)，詳見Http.sys registry settings for IIS。

由于修改這兩個(gè)設(shè)置需要重啟IIS（net stop http, net start http, iisreset），并且只是表面上解決問題，所以我們沒有立即采取這個(gè)方法。又回過頭來在Chrome中查看請(qǐng)求頭，突然發(fā)現(xiàn)cookie的值好長(zhǎng)。

進(jìn)一步查看cookie：

很多cnzz_eid，這是cnzz統(tǒng)計(jì)代碼產(chǎn)生的，可是我們?cè)诓┛椭袥]有使用cnzz。但是，有的用戶博客自己加了cnzz的統(tǒng)計(jì)代碼。我們檢查了一些會(huì)產(chǎn)生"Bad Request - Request Too Long"的頁(yè)面，的確有些加了cnzz的代碼。

我們手動(dòng)在Chrome中刪除了一些帶有cnzz_eid的cookie，問題就解決了。

原來是cnzz惹的禍！

為什么在IE與Firefox中不會(huì)出現(xiàn)這個(gè)問題呢？

可能是IE與Firefox對(duì)于request header過長(zhǎng)的請(qǐng)求會(huì)自動(dòng)截?cái)?；而Chrome對(duì)此置之不理。

小結(jié)

這篇文章分享的內(nèi)容是：當(dāng)IIS返回"Bad Request - Request Too Long. HTTP Error 400. The size of the request headers is too long."的錯(cuò)誤時(shí)，說明客戶端發(fā)出的請(qǐng)求頭長(zhǎng)度超出了Http.sys的限制，這個(gè)限制是由注冊(cè)表"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters"中的兩個(gè)參數(shù)MaxFieldLength與MaxRequestBytes決定的，默認(rèn)值是16384字節(jié)。