cnzz統(tǒng)計代碼引起的Bad Request - Request Too Long的原因分析
問題起因
今天一位網友向我們反饋,用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發(fā)出的請求頭包含過多內容。查看Chrome請求的網址是正常的,也沒發(fā)現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字節(jié),詳見Http.sys registry settings for IIS。
由于修改這兩個設置需要重啟IIS(net stop http, net start http, iisreset),并且只是表面上解決問題,所以我們沒有立即采取這個方法。又回過頭來在Chrome中查看請求頭,突然發(fā)現cookie的值好長。
進一步查看cookie:
很多cnzz_eid,這是cnzz統(tǒng)計代碼產生的,可是我們在博客中沒有使用cnzz。但是,有的用戶博客自己加了cnzz的統(tǒng)計代碼。我們檢查了一些會產生"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."的錯誤時,說明客戶端發(fā)出的請求頭長度超出了Http.sys的限制,這個限制是由注冊表"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters"中的兩個參數MaxFieldLength與MaxRequestBytes決定的,默認值是16384字節(jié)。
版權聲明:本站文章來源標注為YINGSOO的內容版權均為本站所有,歡迎引用、轉載,請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站,禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像,否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯網收集整理而來,僅供學習參考,不代表本站立場,如有內容涉嫌侵權,請聯系alex-e#qq.com處理。