Chrome插件之ModHeader

 

1、ModHeader是什麼

ModHeader顧名思義就是讓咱們能夠自定義HTTP請求頭或者是重寫響應頭，包括新增請求頭/響應頭或者覆蓋Chrome瀏覽器設置的請求頭的默認值，同時還能夠根據URL Pattern來只對特定網站生效。

Request header用來定義請求頭，Response header用來定義響應頭，Filter用來設置針對特定網站生效：

 

 

2、在爬蟲開發中的應用場景

2.1 爬取網站時的語言設置問題

爲何我須要這麼一款看上去沒啥用的插件呢？由於在實際的爬蟲任務中碰到一個問題，要爬取的網站是個國外的網站，而如今稍具規模的網站都喜歡搞國際化，就是針對不一樣國家的訪客顯示不一樣的語言，理論上這樣對用戶更友好（實際上國際化若是作得不夠好的話會有點奇怪...），這樣就不用讓用戶再去找翻譯軟件翻譯了，並且國際化是人設置的理論上要比翻譯軟件更好一些。

那國際化是經過什麼實現的呢？HTTP請求頭有一項叫作Accept-Language，就是用來向服務器聲明應該優先給本身顯示什麼語言。Chrome瀏覽器在發送請求的時候會根據瀏覽器當前的語言偏好設置這個請求頭的值：

好比個人瀏覽器設置如上圖，而後請求時Chrome就會將Accept-Language設置成這樣的：

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

目標網站雖然是外國網站，可是它接收到個人請求而後從請求頭中拿出Accept-Language一看，呦，稀客呀，有zh-CN，說明訪客要求優先查看簡體中文，而後它就從配置好的一個國際化文件中取出中文的語言配置，這個配置文件簡陋點的話就相似於這種：

cn.welcome=歡迎訪問咱們的網站
cn.vote=頂
cn.next_page=下一頁
cn.previous_page=上一頁

而後HTML頁面上對應的位置都不直接寫常量而是用一個變量來代替，變量就對應着上面這個配置文件中的鍵名去除cn.以後的部分，好比${vote}，這樣根據不一樣狀況加載不一樣語言配置文件而後使用變量的值渲染頁面就能夠實現顯示不一樣語言，可是理想很豐滿，現實很骨感，上面這個配置文件並不必定能覆蓋到頁面中的全部變量，也就是說如今頁面上有一個foo變量在上面的配置文件中找不到對應的中文值怎麼辦，總不能空着吧，算了就先拿默認語言英文頂一下吧，因而就出現了有坑爹的國際化一半中文一半英文。這對人來講固然無所謂，可是對於程序來講區別就很大了，若是在程序中手動設置Accept-Language的話，好比我手動設置了優先中文，那麼不少東西都會變成我所熟悉的，舉個例子好比數字的顯示方式，在咱們國家使用逗號作千位分隔符，使用點作小數分隔符，好比一千零一點一，在咱們國家通常會寫成成「1,001.1」，而在某些歐洲國家，正好是反着來的，它們使用逗號作小數分隔符，使用點作千位分隔符，就會寫作「1.001,1」，乍一看是讓人懵逼的（維基百科 - 小數點），同理還有對日期的顯示，若是能將這些使用中國的方式顯示，看起來和解析起來都會爽不少，但是它們這種迷之國際化頁面中哪些是中文哪些是英文是不受我控制的，頗有可能他們稍稍一改個人程序就掛了，或者某個關鍵字段以前是用英文顯示的某一天忽然變中文了...寫代碼時應該儘可能減小不可控因素所佔的比重，因此沒有特殊狀況的話，咱們在爬取一個網站時使用的語言應該儘可能是這個網站的默認語言，即不設置Accept-Language這個請求頭便可。

可是另外一個問題又來了（我勒個天跑題半天終於繞回來了），我程序中沒有設置Accept-Language，而後我熱心腸的Chrome瀏覽器幫我設置了Accept-Language，而後我在Chrome中使用開發者工具排查問題時看到的頁面的語言就跟我程序中的不一致，若是調整Chrome的語言設置的話雖然能解決問題可是這個設置是全局的會對全部網站都有影響，搞很差我之後訪問一個有國際化的中文網站，它一看個人Accept-Language是以en打頭的二話不說返回給了我英文版的網站，我找誰說理去...這個時候終於輪到在門外站了半天的ModHeader出場了，使用ModHeader將Chrome瀏覽器的Accept-Language調整爲和程序中的一致便可，即手動設置爲想要的語言或置空，而後在URL Pattern只匹配目標網站，這樣至少在瀏覽器中看到的語言和程序中是一致的，並且對訪問其它站點也沒有影響，也算是爬取國外網站調試的一個小技巧吧。

最後解釋一下爲何國際化使用Accept-Language而不是基於IP作判別，由於基於IP的話容易誤判，好比掛了代理，好比肉身翻~牆（居然會被斷定爲敏感字沒想到博客園也搞這一套...）想使用母語等狀況，而Accept-Language通常都是瀏覽器設置的，瀏覽器更知道當前的系統環境應該是哪一種語言在安裝時就能夠自動設置爲正確的語言，而後又提供了修改途徑來讓用戶能夠手動修正，這種方式更可靠。

 

2.2 藉助ModHeader來檢測必需要設置的請求頭

不少網站都會有簡單的反爬措施，比較常見的是加密參數，加密參數的其中一種形式是使用自定義的請求頭來設置，好比下面這個請求頭：

:authority: api.joom.com
:method: GET
:path: /1.1/products/1498834929187697429-213-1-709-71790600/sizeTables?currency=USD&language=en-US&_=joaauqxc
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9,en;q=0.8
authorization: Bearer SEV0001MTU0MTc0ODc0N3xoSjZTMmF4TFp0MVZrQkgwcXc4X3cwVGRiX0dseFM0RjRVZS04Nk1Benl1X01YSHZKb3loSEFYT2IzQUVXOXdvRDJuSktScW4zbUpQd0tYTHlkendxQU9VdWZjSUVQVEJROGNGSW9qMFdUNHJpdllfUXlmd2NteVYxUVFaMUc3VS1mNk8yZXoxTnhuTWs4S1VVdTV2bU5xeExBZzlhMjZqTmpWdkRQc0FjbWVpMDFNPXz8wew7uOVGWgeKLikgiRVDi4EmSZ3N2dmd-5sz1ZKJDg==
origin: https://www.joom.com
referer: https://www.joom.com/en/products/1498834929187697429-213-1-709-71790600?context=%7B%22type%22%3A%22product%22%2C%22value%22%3A%5B%7B%22id%22%3A%221498834929187697429-213-1-709-71790600%22%2C%22type%22%3A%22pg%22%2C%22data%22%3A%22y8uHh4eH%2BflmZgEBAAAAAO1HA4bkpTdGfDfwd76maex7tY%2BDeOsoQUhHQ7m2bGbcRnL8SepQJnnjmW%2B10ic5dGbC4wTPTC6G%2FdUSDzg9vvCpZbGGn0A9FvtSYWiLaNQDYhLKWRek418JZf6%2FPEoE4uZrORmz2FOLRVs8jawo0mOraVj7rNDBuV5zDpWydGl4sCqPbnyg4zpOuTc%2FM418b4ysw%2BflK73seqQVTEKL4wf1J7sS8PX6EC%2Bpz3QhJdFzxIZc7jcjd%2BtWupz56QyQ53V4tyHQH0c%2Bu7tMzGXLkfnEC8je6m4tjnpJzuwV%2Frb%2FxFSyas0dJ73s%2BgFBPnLHnDdj9vDqklT3iEf2F8GCKBVK48lY8AWNcv%2B0kNzAprv6cXnXfH%2Fu0B0kbrEy4BRIr3Kh5lgbtkI6hU%2FXmwsRPYAWR9FVlTsLNQelBHe0yfRYz5rZhuRLd69n8q%2BKSdGPVXY58SWRmHxVtQDUxFCgqQQnMJX3DtnN1adOarhUzlEp%22%7D%5D%7D&contextSeed=1nk09
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
x-api-token: Uq4BiAM0c5yL22uuODvHe7GkBYSIDfVv
x-ostype: Windows
x-version: 0.1.15

其中的兩個參數x-api-token和authorization看上去很可疑，怎麼快速肯定哪一個請求頭是必需要設置的呢？咱們可不想花費太多時間在非必要參數上，固然能夠寫點代碼一點一點測試出來，好，如今來將難度再升級一下，假如這些參數都是動態生成的，每次都不同，即便將它們的值複製到程序中也不能用，也就是要在程序中模擬必需要先搞清楚這些值是如何來的，但是又不想花半天時間好不容易搞清楚一個請求頭怎麼來的忽然發現這個請求頭不設置也能夠，只好在內心默默流淚... (╥╯^╰╥)

這個時候能夠藉助ModHeader在瀏覽器中將懷疑的請求頭的值設置爲空，即模擬不傳遞此請求頭的行爲，而後刷新一下看看會發生什麼事，好比上面的那個例子，頁面地址：https://www.joom.com/en/products/1498834929187697429-213-1-709-71790600?context=%7B%22type%22%3A%22product%22%2C%22value%22%3A%5B%7B%22id%22%3A%221498834929187697429-213-1-709-71790600%22%2C%22type%22%3A%22pg%22%2C%22data%22%3A%22y8uHh4eH%2BflmZgEBAAAAAO1HA4bkpTdGfDfwd76maex7tY%2BDeOsoQUhHQ7m2bGbcRnL8SepQJnnjmW%2B10ic5dGbC4wTPTC6G%2FdUSDzg9vvCpZbGGn0A9FvtSYWiLaNQDYhLKWRek418JZf6%2FPEoE4uZrORmz2FOLRVs8jawo0mOraVj7rNDBuV5zDpWydGl4sCqPbnyg4zpOuTc%2FM418b4ysw%2BflK73seqQVTEKL4wf1J7sS8PX6EC%2Bpz3QhJdFzxIZc7jcjd%2BtWupz56QyQ53V4tyHQH0c%2Bu7tMzGXLkfnEC8je6m4tjnpJzuwV%2Frb%2FxFSyas0dJ73s%2BgFBPnLHnDdj9vDqklT3iEf2F8GCKBVK48lY8AWNcv%2B0kNzAprv6cXnXfH%2Fu0B0kbrEy4BRIr3Kh5lgbtkI6hU%2FXmwsRPYAWR9FVlTsLNQelBHe0yfRYz5rZhuRLd69n8q%2BKSdGPVXY58SWRmHxVtQDUxFCgqQQnMJX3DtnN1adOarhUzlEp%22%7D%5D%7D&contextSeed=1nk09。

首先屏蔽掉x-api-token這個請求頭：

而後刷新網頁，觀察請求數據的那個ajax請求的請求頭：

x-api-token這個請求頭沒有設置依然返回了數據，說明它應該不是必要參數，沒必要再在這上面花費力氣了。

再來試一下authorization：

 

清除緩存刷新：

 

不傳這個參數頁面直接掛掉了，連去請求商品詳情的ajax請求都沒有發送，說明這個參數應該是必須的，可以使用一樣方法排查其它請求頭。

總結：使用ModHeader快速肯定哪些請求頭是必須的，提升分析目標網站的效率。

 

.