長沙做網(wǎng)站官方站點精彩分享

亚洲国产私拍精品国模在线观看,人妻中出受孕 中文字幕在线,3D动漫精品啪啪一区二区免费,亚洲AV色福利天堂

如何查看web網(wǎng)站服務器頭部信息?

[ 1920 查看 / 0 回復 ]

通過工具可以查詢到站點服務器信息與程序信息及版本,其實這是通過服務器響應頭信息里返回的,如果把這些信息暴露出去對站點不安全,我們可以通過隱藏或修改頭信息的方法來阻止這些信息暴露

  頭信息包含服務器信息與程序信息

  有些查詢工具在我們輸入某個站點的URL后就能判斷這個站點的WebServer與程序類型。

  例如在站長工具下csjwang.com站點:

  查詢豆瓣的

  這個工具重點在于它可以檢測出站點的服務器類型與程序類型,它是依據(jù)什么途徑獲取服務器類型與程序支持的信息呢?我們用Chrome打開剛才測試用的guofei.me站點,看服務器響應頭信息

  剛才利用工具檢測出的服務器與程序支持的信息都在站點響應的頭信息里,這些信息都是web服務器軟件輸出的,不同的web服務器還有不同的輸出,比如tomcat的。

  HTTP服務器頭部Header信息詳解

  1. Accept:告訴WEB服務器自己接受什么介質類型,*/* 表示任何類型,type/* 表示該類型下的所有子類型,type/sub-type。

  2. Accept-Charset:  瀏覽器申明自己接收的字符集
  Accept-Encoding: 瀏覽器申明自己接收的編碼方法,通常指定壓縮方法,是否支持壓縮,支持什么壓縮方法(gzip,deflate)
  Accept-Language::瀏覽器申明自己接收的語言
  語言跟字符集的區(qū)別:中文是語言,中文有多種字符集,比如big5,gb2312,gbk等等。

  3. Accept-Ranges:WEB服務器表明自己是否接受獲取其某個實體的一部分(比如文件的一部分)的請求。
  bytes:表示接受,none:表示不接受。

  4. Age:當代理服務器用自己緩存的實體去響應請求時,用該頭部表明該實體從產生到現(xiàn)在經(jīng)過多長時間了。

  5. Authorization:當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時,用該頭部來回應自己的身份驗證信息給WEB服務器。

  6. Cache-Control:請求:no-cache(不要緩存的實體,要求現(xiàn)在從WEB服務器去?。?br />  max-age:(只接受 Age 值小于 max-age 值,并且沒有過期的對象)
  max-stale:(可以接受過去的對象,但是過期時間必須小于 max-stale 值)
  min-fresh:(接受其新鮮生命期大于其當前 Age 跟 min-fresh 值之和的緩存對象)
  響應:public(可以用 Cached 內容回應任何用戶)
  private(只能用緩存內容回應先前請求該內容的那個用戶)
  no-cache(可以緩存,但是只有在跟WEB服務器驗證了其有效后,才能返回給客戶端)
  max-age:(本響應包含的對象的過期時間)
  ALL: no-store(不允許緩存)

  7. Connection:請求:close(告訴WEB服務器或者代理服務器,在完成本次請求的響應后,斷開連接,不要等待本次連接的后續(xù)請求了)。
  keepalive(告訴WEB服務器或者代理服務器,在完成本次請求的響應后,保持連接,等待本次連接的后續(xù)請求)。
  響應:close(連接已經(jīng)關閉)。
  keepalive(連接保持著,在等待本次連接的后續(xù)請求)。
  Keep-Alive:如果瀏覽器請求保持連接,則該頭部表明希望 WEB 服務器保持連接多長時間(秒)。
  例如:Keep-Alive:300

  8. Content-Encoding:WEB服務器表明自己使用了什么壓縮方法(gzip,deflate)壓縮響應中的對象。
  例如:Content-Encoding:gzip
  Content-Language:WEB 服務器告訴瀏覽器自己響應的對象的語言。
  Content-Length: WEB 服務器告訴瀏覽器自己響應的對象的長度。
  例如:Content-Length: 26012
  Content-Range:  WEB 服務器表明該響應包含的部分對象為整個對象的哪個部分。
  例如:Content-Range: bytes 21010-47021/47022
  Content-Type:    WEB 服務器告訴瀏覽器自己響應的對象的類型。
  例如:Content-Type:application/xml

  9. ETag:就是一個對象(比如URL)的標志值,就一個對象而言,比如一個 html 文件,如果被修改了,其 Etag 也會別修改,
  所以,ETag 的作用跟 Last-Modified 的作用差不多,主要供 WEB 服務器判斷一個對象是否改變了。
  比如前一次請求某個 html 文件時,獲得了其 ETag,當這次又請求這個文件時,瀏覽器就會把先前獲得的 ETag 值發(fā)送給
  WEB 服務器,然后 WEB 服務器會把這個 ETag 跟該文件的當前 ETag 進行對比,然后就知道這個文件有沒有改變了。

  10. Expired:WEB服務器表明該實體將在什么時候過期,對于過期了的對象,只有在跟WEB服務器驗證了其有效性后,才能用來響應客戶請求。
  是 HTTP/1.0 的頭部。
  例如:Expires:Sat, 23 May 2009 10:02:12 GMT

  11. Host:客戶端指定自己想訪問的WEB服務器的域名/IP 地址和端口號。

  例如:Host:rss.sina.com.cn

  12. If-Match:如果對象的 ETag 沒有改變,其實也就意味著對象沒有改變,才執(zhí)行請求的動作。
  If-None-Match:如果對象的 ETag 改變了,其實也就意味著對象也改變了,才執(zhí)行請求的動作。

  13. If-Modified-Since:如果請求的對象在該頭部指定的時間之后修改了,才執(zhí)行請求的動作(比如返回對象),否則返回代碼304,告訴瀏覽器 該對象沒有修改。
  例如:If-Modified-Since:Thu, 10 Apr 2008 09:14:42 GMT
  If-Unmodified-Since:如果請求的對象在該頭部指定的時間之后沒修改過,才執(zhí)行請求的動作(比如返回對象)。

  14. If-Range:瀏覽器告訴 WEB 服務器,如果我請求的對象沒有改變,就把我缺少的部分給我,如果對象改變了,就把整個對象給我。
  瀏覽器通過發(fā)送請求對象的 ETag 或者 自己所知道的最后修改時間給 WEB 服務器,讓其判斷對象是否改變了。
  總是跟 Range 頭部一起使用。

  15. Last-Modified:WEB 服務器認為對象的最后修改時間,比如文件的最后修改時間,動態(tài)頁面的最后產生時間等等。
  例如:Last-Modified:Tue, 06 May 2008 02:42:43 GMT

  16. Location:WEB 服務器告訴瀏覽器,試圖訪問的對象已經(jīng)被移到別的位置了,到該頭部指定的位置去取。
  例如:Location:http://i0.sinaimg.cn/dy/deco/2008/0528 /sinahome_0803_ws_005_text_0.gif

  17. Pramga:主要使用 Pramga: no-cache,相當于 Cache-Control: no-cache。
  例如:Pragma:no-cache

  18. Proxy-Authenticate: 代理服務器響應瀏覽器,要求其提供代理身份驗證信息。
  Proxy-Authorization:瀏覽器響應代理服務器的身份驗證請求,提供自己的身份信息。

  19. Range:瀏覽器(比如 Flashget 多線程下載時)告訴 WEB 服務器自己想取對象的哪部分。
  例如:Range: bytes=1173546-

  20. Referer:瀏覽器向 WEB 服務器表明自己是從哪個 網(wǎng)頁/URL 獲得/點擊 當前請求中的網(wǎng)址/URL。
  例如:Referer:http://www.sina.com/

  21. Server: WEB 服務器表明自己是什么軟件及版本等信息。
  例如:Server:Apache/2.0.61 (Unix)

  22. User-Agent: 瀏覽器表明自己的身份(是哪種瀏覽器)。
  例如:User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

  23. Transfer-Encoding: WEB 服務器表明自己對本響應消息體(不是消息體里面的對象)作了怎樣的編碼,比如是否分塊(chunked)。
  例如:Transfer-Encoding: chunked

  24. Vary: WEB服務器用該頭部的內容告訴 Cache 服務器,在什么條件下才能用本響應所返回的對象響應后續(xù)的請求。
  假如源WEB服務器在接到第一個請求消息時,其響應消息的頭部為:Content-Encoding: gzip; Vary: Content-Encoding
  那么 Cache 服務器會分析后續(xù)請求消息的頭部,檢查其 Accept-Encoding,是否跟先前響應的 Vary 頭部值一致,即是否使用
  相同的內容編碼方法,這樣就可以防止 Cache 服務器用自己 Cache 里面壓縮后的實體響應給不具備解壓能力的瀏覽器。
  例如:Vary:Accept-Encoding

  25. Via: 列出從客戶端到 OCS 或者相反方向的響應經(jīng)過了哪些代理服務器,他們用什么協(xié)議(和版本)發(fā)送的請求。
TOP