問(wèn)題起因
今天一位網(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都沒(méi)問(wèn)題，唯有Chrome。
之前我們遇到過(guò)一次這樣的問(wèn)題，當(dāng)時(shí)以為是偶然因素引起的Chrome問(wèn)題，于是在"%LOCALAPPDATA%\Google\&;中將Chrome的配置文件重命名，讓Chrome重建配置，解決了問(wèn)題。
今天，這個(gè)問(wèn)題再次出現(xiàn)，就不能忽視了，必須找出問(wèn)題的真正原因并找到解決辦法。
解決過(guò)程
開始我們推測(cè)，可能是某些原因造成Chrome發(fā)出的請(qǐng)求頭包含過(guò)多內(nèi)容。查看Chrome請(qǐng)求的網(wǎng)址是正常的，也沒(méi)發(fā)現(xiàn)Request Header的異常。既然沒(méi)在Chrome找到問(wèn)題的原因，那我們從服務(wù)端下手吧，請(qǐng)求長(zhǎng)就長(zhǎng)一點(diǎn)，只要能讓用戶看到正常的內(nèi)容。
服務(wù)端IIS究竟在哪個(gè)地方返回這個(gè)錯(cuò)誤的？開始以為是Request Filtering Module，調(diào)整了Request Limits設(shè)置不能解決問(wèn)題，禁用Request Filtering Module也解決不了問(wèn)題。
后來(lái)在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é)，詳見(jiàn)Http.sys registry settings for IIS。
由于修改這兩個(gè)設(shè)置需要重啟IIS（net stop http, net start http, iisreset），并且只是表面上解決問(wèn)題，所以我們沒(méi)有立即采取這個(gè)方法。又回過(guò)頭來(lái)在Chrome中查看請(qǐng)求頭，突然發(fā)現(xiàn)cookie的值好長(zhǎng)。
進(jìn)一步查看cookie：
很多cnzz_eid，這是cnzz統(tǒng)計(jì)代碼產(chǎn)生的，可是我們?cè)诓┛椭袥](méi)有使用cnzz。但是，有的用戶博客自己加了cnzz的統(tǒng)計(jì)代碼。我們檢查了一些會(huì)產(chǎn)生"Bad Request - Request Too Long"的頁(yè)面，的確有些加了cnzz的代碼。
我們手動(dòng)在Chrome中刪除了一些帶有cnzz_eid的cookie，問(wèn)題就解決了。
原來(lái)是cnzz惹的禍！
為什么在IE與Firefox中不會(huì)出現(xiàn)這個(gè)問(wèn)題呢？
可能是IE與Firefox對(duì)于request header過(guò)長(zhǎng)的請(qǐng)求會(huì)自動(dòng)截?cái)啵欢鳦hrome對(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í)，說(shuō)明客戶端發(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é)。
