整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
、狀態碼中文
100:“繼續”，
101:“交換協議”，
200：“好的”，
201:“已創建”，
202:“接受”，
203:“非權威信息”，
204:“無內容”，
205:“重置內容”，
206:“部分內容”，
300:“多選”，
301:“永久移動”，
302:“找到”，
303:“見其他”，
304:“未修改”，
305:“使用代理”，
307:“臨時重定向”，
400:“錯誤請求”，
401:“未授權”，
402:“需要支付”，
403:“禁止”，
404:“未找到”，
405:“方法不允許”，
406:“不可接受”，
407:“需要代理驗證”，
408:“請求超時”，
409:“沖突”，
410:“消失”，
411:“長度要求”，
412:“前置失敗”，
413:“請求實體太大”，
414:“請求URI太長”，
415:“不支持的媒體類型”，
416:“請求的范圍不可滿足”，
417:“期望失敗”，
422:“不可處理實體”，
500:“內部服務器錯誤”，
501:“未實現”，
502:“壞網關”，
503:“服務不可用”，
504:“網關超時”，
505:“不支持HTTP版本”
二、狀態碼英文
108:"Continue"
191:"Switching Protocols"208OK
201:"Created"202:"Accepted"
203:"Non-Authoritative Information"
284:"No Content"
205"Reset Content"
206"Partial Content"398:"Multiple Choice"
301:"Moved Permanently"
392"Found"
303:"See Other"
384:"Not Modified",
305:"Use Proxy"
307:"Temporary Redirect"
408:"Bad Request"401:"Unauthorized"
402:"Payment Required"
403:"Forbidden"
484:"Not Found"
405:"Method Not Allowed"
486:"Not Acceptable"
497:"Proxy Authentication Required",
408:"Request Timeout"
409:"Conflict"
410:"Gone"
411:"Length Required".
412:"precondition Failed"
413:"Request Entity Too Large",
414:Request-URI Too Long",
415"Unsupported edia Type".
416"Requested Range Not Satisfiable"
417Expectation Failed"
422:Unprocessable Entity"500"Internal Server Error"
501:"Not Implemented"
502"Bad Gateway"
503:Service Unavailable".
504:Gateway Timeout"
505:"HTTP Version Not Supported"三、HTTP Responses Header 響應頭
Accept-Ranges 表明服務器是否支持指定范圍請求及哪種類型的分段請求 Accept-Ranges:bytes
Age 從原始服務器到代理緩存形成的估算時間（以秒計，非負）Age:12
Allow 對某網絡資源的有效的請求行為，不允許則返回405 Allow:GET, HEAD
Cache-Control 告訴所有的緩存機制是否可以緩存及哪種類型 Cache-Control:no-cache
Content-Encodingweb服務器支持的返回內容壓縮編碼類型。 Content-Encoding:
Content-Language 響應體的語言Content-Language:en,zh
Content-Length 響應體的長度Content-Length: 348
Content-Location 請求資源可替代的備用的另一地址 Content-Location:/index.html
Content-MD5 返回資源的MD5校驗值 Content-MD5:Q2hlY2sgSW50ZWdyaXR5IQ==Content-Range 在整個返回體中本部分的字節位置Content-Range:bytes 21010-47021/47022
Content-Type 返回內容的MIME類型 Content-Type:text/html; charset=utf-8
Date 原始服務器消息發出的時間 Date:Tue, 15 Nov 2010 08:12:31 GMT
ETag 請求變量的實體標簽的當前值 ETag:“737060cd8c284d8af7ad3082f209582d”
Expires 響應過期的日期和時間 Expires: Thu, 01 Dec2010 16:00:00 GMT
Last-Modified 請求資源的最后修改時間 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 Location:http://www.zcmhi.com/archives/94.html
Pragma 包括實現特定的指令，它可應用到響應鏈上的任何接收方 Pragma:no-cache
Proxy-Authenticate 它指出認證方案和可應用到代理的該URL上的參數 Proxy-Authenticate:Basic
refresh 應用于重定向或一個新的資源被創造，在5秒之后重定向（由網景提出，被大部分瀏覽器支持）Refresh: 5;url=http://www.zcmhi.com/archives/94.html
Retry-After 如果實體暫時不可取，通知客戶端在指定時間之后再次嘗試 Retry-After:120
Server web服務器軟件名稱 Server: Apache/1.3.27(Unix) (Red-Hat/Linux)
Set-Cookie 設置HttpbCookie Set-Cookie:UserID=JohnDoe; Max-Age=3600; Version=1
Trailer 指出頭域在分塊傳輸編碼的尾部存在 Trailer:Max-Forwards
Transfer-Encoding 文件傳輸編碼 Transfer-Encoding:chunked
Vary 告訴下游代理是使用緩存響應還是從原始服務器請求 Vary:*
Via 告知代理客戶端響應是通過哪里發送的 Via:1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning 警告實體可能存在的問題 Warning: 199 Miscellaneous warning
WWW-Authenticate 表明客戶端請求實體應該使用的授權方案 WWW-Authenticate:Basic
Access-Control-Allow-Origin 跨域 *四、HTTP Request Header 請求頭
題
響應頭是在服務器發送頁面的HTML代碼之前，從服務器發送到瀏覽器。這些頭信息包含著關于下列內容的有用信息：服務器希望的通信方式，頁面類型，以及諸如截止日期和內容類型這樣的元數據。響應是獲取Web應用的先關信息的絕佳來源，對于我們想通過它實現的特殊功能來說，尤其如此。
響應頭是攻擊者用于查找應用特有信息的地方。與你的Web服務器和平臺相關的信息將會作為標準請求的一部分被泄露出去。
解決方案
正如3.3節中所提到的，你可以在請求頭旁邊找到響應頭，也可以通過代理來找到頭信息，比如WebScarb。我們將利用這項任務來向你介紹TamperData,它是一個方便的工具，可以用在這項任務和其他幾項任務中。
按照2.2節，安裝TamperData。它的安裝方法與大多數附加組件相同。
從“工具”菜單中打開TamperData，然后瀏覽到某個頁面。在TamperData窗口中，你會發現它列舉出了訪問過的頁面，這與WebScarab和FireBug是一樣的。單擊某個頁面，就會顯示出請求頭和響應頭，如圖3-12所示。
討論
響應頭和響應本身之間存在著差別。響應頭描述響應，它們是元數據。例如，響應頭通常會包含以下內容：
狀態（Status）
內容類型（Content-Type）
內容編碼（Content-Encoding）
內容長度（Content-Length）
截止日期（Expire）
追后修改時間（Last-Modified）
多年來，響應頭有所演化，因此，最初的規范（可以從http:///http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html訪問）只對其中某些項（比如狀態）而言是正確的。
另外，有些響應頭會顯示。服務器軟件以及響應發出的日期和時間。如果你允許Internet上的每個人看到你正在使用的服務器和平臺，那么現在就應該確保你安裝了最新的補丁，并阻止了一切已知的漏洞。
請特別注意Content-Type頭信息。大多數時間它只不過是像“text/html;charset=UFT-8”這樣的內容，表示正常的HTML響應和編碼。不過，它也可能引用外部應用或引起異常的瀏覽器行為，而這些異常之處正式攻擊可能悄悄潛入的地方。
例如，已知有些舊版的PDF閱讀器會執行通過查詢字符串傳入的JavaScript（詳細情況請訪問http://www.adobe.com/support/security/advisories/apsa07-01.html）。如果你的應用提供PDF，那么它是直接將Content-Type設置為applicant/pdf嗎？又或者它設置了Content-Disposition頭信息，要求用戶先下載PDF，從而避免了任何JavaScript趁虛而入？
動態重定向是另一項危險的特性，因為它們可能會被攻擊者用來將惡意網站的鏈接偽裝成你的網站的鏈接，從而濫用了用戶對你的網站的信任。作為鏈接，動態重定向通常具有如下形式：
http：//www.example.com/reirect.php?url=http://ha.ckers.org可以看到，這些細節可能很難對付。如果你的應用使用某種特殊的頭信息來處理文件上傳、下載、重定向或任何其他事務，那么請確保研究了所有具體的安全防范措施，因為實際的危險要比這里所能列出的還要多。
新的響應頭仍在不斷地被開發出來。TrackBack、PingBack和RefBack是一種新的、通常被稱為LinkBack的Web功能的相互競爭的標準。這些LinkBack提供了一種雙向的鏈接功能。它們因為迎合了當前的博客熱而備受歡迎。
例如，如果Fred從自己的博客鏈接到Wilma的博客，那么他們的博客托管服務可以使用某種標準進行通信，于是Wilma的博客將顯示Fred鏈接到她的博客。HTTP頭可幫助識別使用的是哪些標準，并傳送鏈接信息。
搜索微信公眾號：TestingStudio霍格沃茲的干貨都很硬核
了提升瀏覽器加載頁面資源的性能，對于js、css、圖片等靜態資源，web服務器往往會通過Cache-Control、ETag/If-None-Match、Last-Modified/If-Modified-Since、Pragma、Expires、Date、Age等頭部來控制、管理、檢測這類資源對緩存機制的使用情況。同時，為了使新版本的js、css等資源立即生效，一種比較通行的做法是為js、css這些文件名添加一個hash值。這樣當js、css內容發生變化時，瀏覽器獲取的是不同的js、css文件。在這種情況下，舊版本的index.html文件可能是這樣的：
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8>
<title>測試</title>
<meta http-equiv=X-UA-Compatible content="IE=Edge">
<meta name=viewport content="width=device-width,minimum-scale=1,maximum-scale=1">
<link href=/static/css/main.4656e35c1e8d4345f5bf.css rel=stylesheet>
</head>
<style>
html, body {
width: 100%;
}
</style>
<body>
<div id=newMain></div>
<script type=text/javascript src=/static/js/main-4656e35c1e8d4345f5bf.js></script>
</body>
</html>
當項目的js、css內容發生了變化時，新版本的index.html文件內容變成這樣的(js和css文件名攜帶了新的hash值1711528240049）：
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8>
<title>測試</title>
<meta http-equiv=X-UA-Compatible content="IE=Edge">
<meta name=viewport content="width=device-width,minimum-scale=1,maximum-scale=1">
<link href=/static/css/main.1711528240049.css rel=stylesheet>
</head>
<style>
html, body {
width: 100%;
}
</style>
<body>
<div id=newMain></div>
<script type=text/javascript src=/static/js/main-1711528240049.js></script>
</body>
</html>
因為index.html文件一般會設置為不緩存，這樣用戶每次訪問首頁時，都會從web服務器重新獲取index.html，然后根據index.html中的資源文件是否變化，從而決定是否使用緩存的文件。這樣既能讓用戶立即獲取最新的js、css等靜態資源文件，又能充分地使用緩存。index.html的響應頭大概長這樣：
但是為了保證系統的高可用，web后端往往由多個實例提供服務，用戶請求會在多個服務實例間進行負載均衡。而系統升級過程中，會存在多個版本共存的現象。這時，如果用戶從舊版本實例上獲取了index.html文件，然后再去獲取舊版本的js、css文件(main-4656e35c1e8d4345f5bf.js和main.4656e35c1e8d4345f5bf.css），但是請求卻分發到了新版本服務實例上，這時因為新版本服務實例只有main-1711528240049.js和main.1711528240049.css文件，就會導致訪問失敗。反過來，如果從新版本實例上獲取了index.html文件，在請求相應的js、css文件時，也可能被分發到舊版本實例上，也導致訪問失敗。
解決方法：
1）首先，改造一下index.html文件中引用js、css等靜態資源的路徑，添加一個版本號，如v1、v2，這樣index.html文件對js、css的引用變為：
<link href=/static/v1/css/main.1711528240049.css rel=stylesheet>
<script type=text/javascript src=/static/v1/js/main-1711528240049.js></script>
2）使用灰度發布策略升級系統，具體步驟如下（假設系統包含A、B兩個服務實例）
作者：movee
鏈接：https://juejin.cn/post/7353069220827856946
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
