HTTP系列1 HTTP概述

HTTP是在 Web 上進行數據交換的基礎，是一種 client-server 協議，也就是說，請求一般是由像瀏覽器這樣的接受方發起的。在client和server之間，還有不少proxy實體，如網關/caches。

Client:user-agent

user-agent 就是任何可以爲用戶發起行爲的工具。這個角色一般都是由瀏覽器來扮演。一些例外狀況，好比是工程師使用的程序，以及Web開發人員調試應用程序，一個爬取網頁生成維護搜索引擎索引的機器爬蟲。

瀏覽器來負責發送HTTP請求，並進一步解析HTTP返回的消息，以向用戶提供明確的響應。

web server

Server只是虛擬意義上表明一個機器：它能夠是共享負載（負載均衡）的一組服務器組成的計算機集羣，也能夠是一種複雜的軟件，經過向其餘計算機（如緩存，數據庫服務器，電子商務服務器 ...）發起請求來獲取部分或所有資源。

Server 不必定是一臺機器，但一個機器上能夠裝載的衆多Servers。在HTTP/1.1 和Host頭部中，它們甚至能夠共享同一個IP地址。

Proxies

在應用層上轉發Http消息的服務，是爲代理(Proxies)。代理有如下幾種做用：

• 緩存（能夠是公開的也能夠是私有的，像瀏覽器的緩存）
• 過濾（像反病毒掃描，家長控制...）
• 負載均衡（讓多個服務器服務不一樣的請求）
• 認證（對不一樣資源進行權限管理）
• 日誌記錄（容許存儲歷史信息）

HTTP 是無狀態，有會話的

HTTP是無狀態的：在同一個鏈接中，兩個執行成功的請求之間是沒有關係的。這就帶來了一個問題，用戶沒有辦法在同一個網站中進行連續的交互，好比在一個電商網站裏，用戶把某個商品加入到購物車，切換一個頁面後再次添加了商品，這兩次添加商品的請求之間沒有關聯，瀏覽器沒法知道用戶最終選擇了哪些商品。而使用HTTP的頭部擴展，HTTP Cookies就能夠解決這個問題。把Cookies添加到頭部中，建立一個會話讓每次請求都能共享相同的上下文信息，達成相同的狀態。

注意，HTTP本質是無狀態的，使用Cookies能夠建立有狀態的會話。

MIME類型和Content-type

多用途Internet郵件擴展（MIME）類型 是一種標準化的方式來表示文檔的性質和格式。 它在IETF RFC 6838中進行了定義和標準化。

瀏覽器一般使用MIME類型（而不是文件擴展名）來肯定如何處理文檔；所以服務器設置正確以將正確的MIME類型附加到響應對象的頭部是很是重要的。

通用類型

type/subtype

MIME的組成結構很是簡單；由類型與子類型兩個字符串中間用'/'分隔而組成。並不容許空格存在。type 表示能夠被分爲複數子類的獨立類型。subtype 表示細分後的每一個類型。

MIME類型對大小寫不敏感，可是傳統寫法都是小寫。

獨立類型

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/octet-stream
…

Multipart 類型

multipart/form-data
multipart/byteranges

重要的MIME類型

application/octet-stream

這是應用程序文件的默認值。意思是 未知的應用程序文件 ，瀏覽器通常不會自動執行或詢問執行。瀏覽器會像對待 設置了HTTP頭Content-Disposition 值爲「附件」的文件同樣來對待這類文件。

text/plain

文本文件默認值。意思是 未知的文本文件 ，瀏覽器認爲是能夠直接展現的。

text/css

任何一個CSS文件想要在網頁上被解釋執行就必須爲text/css 文件。可是服務器常常不會分辨出使用.css後綴的CSS文件，而且將其MIME類型設置爲text/plain 或 application/octet-stream 發送：在這種狀況下，文件並不能被瀏覽器識別爲CSS文件而且會被直接忽略。因此特別注意要給CSS文件設置正確的類型。

application/x-www-form-urlencoded

此爲HTML原生form默認的提交方式，提交的數據按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行了 URL 轉碼

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

multipart/form-data

multipart/form-data 可用於HTML表單從瀏覽器發送信息給服務器。做爲多部分文檔格式，它由邊界線（一個由'--'開始的字符串）劃分出的不一樣部分組成。每一部分有本身的實體，以及本身的 HTTP 請求頭，Content-Disposition和 Content-Type 用於文件上傳領域。

能夠經過設置form的enctype 爲 multipart/form-data。
form只支持上兩種和text/plain，侷限性很大。隨着愈來愈多的 Web 站點，尤爲是 WebApp，所有使用 Ajax 進行數據交互以後，咱們徹底能夠定義新的數據提交方式，給開發帶來更多便利。

application/json

application/json 這個 Content-Type 做爲響應頭你們確定不陌生。實際上，如今愈來愈多的人把它做爲請求頭，用來告訴服務端消息主體是序列化後的 JSON 字符串。因爲 JSON 規範的流行，除了低版本 IE 以外的各大瀏覽器都原生支持 JSON.stringify，服務端語言也都有處理 JSON 的函數，使用 JSON 不會趕上什麼麻煩。

JSON 格式支持比鍵值對複雜得多的結構化數據，各大抓包工具如 Chrome 自帶的開發者工具、Firebug、Fiddler，都會以樹形結構展現 JSON 數據，很是友好。

text/xml

它是一種使用 HTTP 做爲傳輸協議，XML 做爲編碼方式的遠程調用規範。典型的 XML-RPC 請求是這樣的：

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

XML-RPC 協議簡單、功可以用，各類語言的實現都有。它的使用也很普遍，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服務等等。JavaScript 中，也有現成的庫支持以這種方式進行數據交互，能很好的支持已有的 XML-RPC 服務。

Content-Type

Content-Type 實體頭部用於指示資源的MIME類型 media type 。

在響應中，Content-Type標頭告訴客戶端實際返回的內容的內容類型。瀏覽器會在某些狀況下進行MIME嗅探，並不必定遵循此標題的值; 爲了防止這種行爲，能夠將標題 X-Content-Type-Options 設置爲 nosniff。

在請求中 (如POST 或 PUT)，客戶端告訴服務器實際發送的數據類型。

句法

Content-Type:media-type;charset;boundary

對於多部分實體，boundary 是必需的，其包括來自一組字符的1到70個字符，已知經過電子郵件網關是很是健壯的，而不是以空白結尾。它用於封裝消息的多個部分的邊界。

HTTPS

HTTPS 網頁中加載的 HTTP 資源被稱之爲 Mixed Content（混合內容），不一樣瀏覽器對 Mixed Content 有不同的處理規則。

經過 CSP 的 block-all-mixed-content 指令，可讓頁面進入對混合內容的嚴格檢測（Strict Mixed Content Checking）模式。在這種模式下，全部非 HTTPS 資源都不容許加載。跟其它全部 CSP 規則同樣，能夠經過如下兩種方式啓用這個指令：
HTTP 響應頭方式：

Content-Security-Policy: block-all-mixed-content

<meta> 標籤方式：

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">