最近Planet上關(guān)于這個(gè)話題有了很多的探討，關(guān)于解決方案，我和刺茄子云舒Kevin他們?cè)谌豪锒加羞^(guò)討論，這兩天又對(duì)apache的處理機(jī)制進(jìn)行了簡(jiǎn)單的分析，到現(xiàn)在思路也漸漸的清晰了。

解決方式有三種，一是WEB服務(wù)器端解決，二是客戶端解決，三是在中間層解決。

1、WEB服務(wù)器端解決以Apache為例，首先會(huì)想到rewrite或者apache module或者，但是測(cè)試會(huì)發(fā)現(xiàn)rewrite和普通的dso module都不行，因?yàn)閍pache在這之前就錯(cuò)誤返回了；于是乎查資料找更早的介入方式，發(fā)現(xiàn)ap_hook技術(shù)可以在很多環(huán)節(jié)插入代碼， 還有apache input filter也是能在較早的地方進(jìn)行輸入過(guò)濾，但是都失敗了；最后翻代碼分析發(fā)現(xiàn)Apache處理頭之后如果有錯(cuò)誤的話是直接返回的，所以除了修改Apache源代碼，在Apache層面是沒法解決的。

2、客戶端解決，也比較容易想到定制400錯(cuò)誤頁(yè)面，里面寫JS來(lái)清COOKIE，但是問題同上定制的頁(yè)面內(nèi)容也是無(wú)法返回到客戶端的。還有就是客戶端軟件了，對(duì)于網(wǎng)站來(lái)說(shuō)，沒有這種能力。

3、云舒提到Iptables之類的介于客戶端和服務(wù)器端之間的七層過(guò)濾的東東，沒有測(cè)過(guò)。Kevin提出用Squid的方式也可以歸入這一類，我也沒有側(cè)過(guò)，但是Squid基本也可以看做是個(gè)Web服務(wù)器。

本來(lái)Web服務(wù)器設(shè)置這個(gè)限制是防止對(duì)Web服務(wù)器的DOS的，結(jié)果反而導(dǎo)致了對(duì)客戶端DOS的可能，說(shuō)到底就是一個(gè)單選題，選擇Server容易被DOS還是Client容易被DOS，那么Apache選擇了前者。Kevin說(shuō)這根本上是瀏覽器的問題，因?yàn)闉g覽器沒有遵守相關(guān)標(biāo)準(zhǔn)中關(guān)于Cookie大小的限制。的確，理想的狀態(tài)就是服務(wù)器端和客戶端在最大的請(qǐng)求頭上達(dá)成一致，但是目前來(lái)看如果沒有造成較大的危害的話，無(wú)論是瀏覽器方面還是WEB服務(wù)器方面都不會(huì)輕易調(diào)整。

所以總的來(lái)說(shuō)，這個(gè)問題是個(gè)難題，預(yù)計(jì)最終的解決將會(huì)由它所造成的危害推動(dòng)。