JavaScript不要越俎代庖css
針對功能設置apihtml
逐步實現功能web
優化編程
實際上和全部網絡標準同樣就是IETF指定的 有RFC指導文檔
HTTP1.0 無長鏈接 -> HTTP1.1 -> +TLS/SSL(密文 安全性) -> http2.0api
JavaScript在瀏覽器中最基礎的部分標準化。
BOM瀏覽器
DOM緩存
其實以前複習記過這方面筆記 雖然沒記完 我基於以前的筆記接着記吧安全
自己是由多行(CR+LF作換行符)數據構成的字符串文本服務器
請求行/狀態行 請求/響應首部字段 通用首部字段 實體首部字段 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。 其餘
一般報文主體等於請求實體可是當發生編碼操做的時候試題內容會發生變化 致使和報文實體產生差別
mime的意義是發送多種數據的多部份對象集合 在請求頭/響應頭中說明mime的類型(content-type首部字段) 而後在主體部分傳輸對應的類型實體
(例子主要就是斷點下載) 這種狀況下 在請求首部加Range 響應首部是 Content-Length Content-Length 針對範圍請求響應會返回206的響應報文 沒法返回範圍請求的時候就會返回200 和完整的實體內容
內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉,而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準。
對於內容協商機制 請求報文的首部有cookie
內容協商的類型有
認證會檢查請求頭字段中的Authorization字段
狀態碼 | 類別 | 緣由短語 |
---|---|---|
1XX | informational | 接受的請求正在處理 |
2XX | Success | 請求正常處理完畢 |
3XX | Redirection | 須要進行附加操做來完成請求 |
4XX | client error | 服務器沒法處理請求 |
5XX | Server error | 服務器處理出錯 |
(當30一、30二、303響應狀態碼返回時,幾乎全部的瀏覽器都會把POST改爲GET,並刪除請求報文內的主體,以後請求會自動再次發送。30一、302標準是禁止將POST方法改變成GET方法的,但實際使用時你們都會這麼作。)
Virtual Host
在相同的IP地址下 因爲虛擬主機能夠寄存多個不一樣主機名 和 域名的網站 所以在發送HTTP請求的時候要指定HOST (HTTP請求頭首部)
中間人身份 每次經過代理服務器轉發請求或者響應 會追加寫入Via頭部信息 代理轉發響應時,緩存代理(Caching Proxy)會預先將資源的副本(緩存)保存在代理服務器上。當代理再次接收到對相同資源的請求時,就能夠不從源服務器那裏獲取資源,而是將以前緩存的資源做爲響應返回。
網管是轉發其餘服務器通訊數據的服務器 網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非HTTP協議服務 網關能夠提升通訊的安全性
隧道是在相隔很遠的客戶端和服務器二者之間進行中轉 並保持雙方通訊鏈接的應用程序 隧道自己不會解析http請求
舉個例子
GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9, /; q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
If-None-Match: "45bae1-16a-46d776ac"
Cache-Control: max-age=0
例子2
HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"
使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容
通用首部字段
首部字段名 | 說明 |
---|---|
Cache-Control | 控制緩存行爲 |
Connection | 逐跳首部,連接的管理 |
Date | 建立報文的日期 |
Pragma | 報文指令 |
Trailer | 報文末端的首部一覽 |
Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
Upgrade | 升級爲其餘協議 |
Via | 代理服務器相關信息 |
Warning | 錯誤通知 |
請求首部字段
首部字段名 | 說明 |
---|---|
Accept | 用戶代理可處理的媒體類型 |
Accept-Charset | 優先的字符集 |
Accept-Encoding | 優先的內容編碼 |
Accept-Language | 優先的天然語言 |
Authorization | web認證信息 |
Expect | 期待服務器的特定行爲 |
From | 用戶的電子郵箱地址 |
Host | 請求資源所在服務器 |
if-Match | 比較實體標記 (ETag) |
if-Modified-Since | 比較資源的更新時間 |
if-None-Match | 比較實體標記 與if-Match相反 |
if-Range | 資源未更新時發送實體Byte的範圍 |
Range | 實體的字節範圍請求 |
Referer | 對請求中的URL原始獲取方 |
TE | 傳輸編碼的優先級 |
User-Agent | HTTP客戶端程序的信息 |
響應首部字段
首部字段名 | 說明 |
---|---|
Accept-Ranges | 是否接收range請求 |
Age | 推算資源建立通過時間 |
ETag | 資源的匹配信息 |
Location | 令客戶端重定向到指定URL |
Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
Retry-After | 對再次發起請求的時機要求 |
Server | Http服務器的安裝信息 |
Vary | 代理服務器緩存的管理信息 |
WWW-Authenticate | 服務器對客戶端的認證信息 |
實體首部字段
首部字段名 | 說明 |
---|---|
Allow | 資源可支持的HTTP方法 |
Content-Encoding | 實體主體適用的編碼方式 |
Content-Language | 實體主體的天然語言 |
Content-Length | 實體主體的大小 |
Content-Location | 替代對應資源的URL |
Content-Md5 | 實體主體的報文摘要 |
Content-Range | 實體主體的位置範圍 |
Content-Type | 實體主體的媒體類型 |
Expires | 實體主體過時後的日期時間 |
Last-Modified | 資源的最後修改日期和時間 |
非正式定義的首部字段
開始狀態管理所使用的Cookie信息 響應首部字段
字段值
首部字段Cookie會告知服務器,當客戶端想得到HTTP狀態管理支持時,就會在請求中包含從服務器接收到的Cookie。接收到多個Cookie時,一樣能夠以多個Cookie形式發送。
PS:cookie愈來愈大 怎麼辦
功能
HTTP/1.1版本的默認鏈接都是持久鏈接。爲此,客戶端會在持久鏈接上連續發送請求。當服務器端想明確斷開鏈接時,則指定Connection首部字段的值爲Close。
HTTP/1.1以前的HTTP版本的默認鏈接都是非持久鏈接。爲此,若是想在舊版本的HTTP協議上維持持續鏈接,則須要指定Connection首部字段的值爲Keep-Alive。
ps : 瀏覽器的緩存機制 !!! http1.0 硬緩存 expires 協商緩存 last-Modified http 1.1 硬緩存 cache-control 協商緩存 Etag
功能
參數 | 功能 |
---|---|
public | 其餘用戶也可使用緩存 |
private | 響應只以特定的用戶做爲對象 |
no-cache | 表示客戶端將不會接收緩存過的響應。因而,「中間」的緩存服務器必須把客戶端請求轉發給源服務器。同時能夠寫參數例如 Cache-control:no-cache=Location 這種時候客戶端接收到這個被指定參數值的首部字段對應的響應報文 將不能使用緩存 |
no-store | 真的不緩存 |
s-maxage | 指定緩存期限 功能和max-age類似 可是 s-maxage 提供適用於多位用戶使用的公共緩存服務器 |
max-age | 設置緩存時間 超過則轉發給源服務器 |
min-fresh | 超過這個時間的資源不新鮮 過了的就不要了 |
max-stale | 指定的緩存資源過時也接受 |
only-if-cache | 表示客戶端僅在緩存服務器本地緩存目標資源的時候纔會要求返回 也就是要求緩存服務器不從新加載響應 若是不能從緩存服務器獲得響應 則返回504 |
HTTP2
HTTP3