Python接口測試之HTTP詳解（十二）

   概述

    超文本傳輸協議 (HTTP) 是一種用於分布式、協作式、超媒體信息系統的應用級協議。這是1990年以來萬維網 (即因特網) 數據通信的基礎。HTTP 是一種通用

和無狀態的協議, 它可以用於其他目的, 以及使用其請求方法、錯誤代碼和標頭的擴展。基本上, HTTP 是一種基於 tcp/ip 的通信協議, 用於在萬維網上傳送數據

(HTML 文件、圖像文件、查詢結果等)。默認端口為 TCP 80, 但也可以使用其他端口。它為計算機提供了一種標准化的通信方式。HTTP 規范指定如何構造客戶端的

請求數據並將其發送到服務器, 以及服務器如何響應這些請求。

 基本功能

  有三基本特性使 HTTP 成為一個簡單但功能強大的協議:

  1、http 是無連接的: http 客戶端, 即瀏覽器啟動 http 請求, 在發出請求后, 客戶端斷開與服務器的連接並等待響應。服務器處理請求並重新與客戶端的連接以發送響應。

  2、http 是獨立於媒體的: 這意味着, 只要客戶端和服務器都知道如何處理數據內容, 任何類型的數據都可以通過 http 發送。客戶端和服務器都需要使用適當的 MIME 類

型來指定內容類型。

  3、http 是無狀態的: 如上所述, http 是無連接的, 它是 http 是無狀態協議的直接結果。服務器和客戶端只在當前請求期間才知道對方。后來, 他們倆都忘了對方。由於協

議的這種性質, 無論是客戶端還是瀏覽器都不能在 web 頁之間的不同請求之間保留信息。http/1.0 使用每個請求/響應交換的新連接, 而 http/1.1 連接可用於一個或多個請求

/響應交換機。

  基本結構

    下圖顯示了 web 應用程序的一個非常基本的體系結構, 並描述了 HTTP 所處的位置:

    

http 協議是一種請求/響應協議, 基於基於客戶端/服務器的體系結構, 其中 web 瀏覽器、機器人和搜索引擎等行為類似於 http 客戶端, web 服務器充當服務器。

Client

HTTP 客戶端以請求方法、URI 和協議版本的形式向服務器發送請求, 后跟一個類似 MIME 的消息, 其中包含請求修飾符、客戶端信息以及通過 tcp/ip 連接的可能的正文內容。

Server

HTTP 服務器使用狀態行進行響應, 包括消息的協議版本和成功或錯誤代碼, 后跟類似 MIME 的消息, 其中包含服務器信息、實體元和可能的實體正文內容。

 PARAMETERS

    這里將列出一些重要的 HTTP 協議參數以及它們在通信中使用的語法。例如, 日期格式、URL 格式等。這將幫助您在編寫 HTTP 客戶端或服務器程序時構造請求和響應消息。

   HTTP VERSION

     HTTP 使用 <major>. <minor> 編號方案來指示協議的版本。http 消息的版本由第一行中的 http 版本字段指示。下面是指定 HTTP 版本號的一般語法:

                                                               HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

    統一資源標識符

      統一資源標識符 (URI) 是簡單格式化的, 包含名稱、位置等的 case-insensitive 字符串, 用於標識資源, 例如網站、web 服務等。用於 HTTP 的 URI 的一般語法如下:

                                                             URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

 如果端口為空或未給定, 則假定端口80為 HTTP, 空 abs_path 等效於 "/" 的 abs_path。在保留的和不安全的集合中的字符與它們的 "%" 十六進制十六進制編碼等效。

    時間格式

      所有 HTTP 日期/時間戳都必須以格林尼治標准時間 (GMT) 表示, 無例外。允許 HTTP 應用程序使用下列三個日期/時間戳表示法:

      Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123

    編碼

     我們使用字符集來指定客戶端首選的字符集。可以列出多個字符集, 用逗號分隔。如果未指定值, 則默認為 US ASCII。

    內容編碼

      內容編碼值表示在通過網絡傳遞內容之前, 已使用編碼算法對其進行編碼。內容編碼是主要用於允許文檔被壓縮或在不丟失身份的情況下進行有用的轉換。所有的內容

編碼值都是 case-insensitive 的。HTTP/1.1 在接受編碼和內容編碼標頭字段中使用內容編碼值, 我們將在后面的章節中看到。

     類型媒體

      HTTP 在內容類型中使用 Internet 媒體類型並接受標頭字段, 以便提供開放式和可擴展的數據類型和文字協商。所有媒體類型的值都在 Internet 指定的數字頒發機構 (IANA)

中注冊。指定媒體類型的常規語法如下:

     

media-type = type "/" subtype *( ";" parameter )

 

 如：

Accept: image/gif

　語言標簽

    HTTP 在接受語言和內容語言字段中使用語言標記。語言標記由一個或多個部分組成: 主要語言標記和可能的空系列子:

language-tag = primary-tag *( "-" subtag )

 

 標簽內不允許空格, 所有標簽都是 case-insensitive 的。其中任何兩個字母的主標簽是一個 ISO-639 的語言縮寫和任何兩個字母的初始子是一個 ISO-3166 國家代碼。

   消息

HTTP 基於客戶端-服務器體系結構模型和一個無狀態請求/響應協議, 它通過在可靠的 tcp/ip 連接之間交換消息來操作。 http "客戶端" 是一個程序 (Web 瀏覽器或任何其他

客戶端), 它為發送一個或多個 http 請求消息而建立到服務器的連接。http "服務 器" 是一個程序 (通常是像 Apache web 服務器或 Internet 信息服務 IIS 等的 web 服務器),

它接受連接以通過發送 http 響應消 息來服務 http 請求。 HTTP 使用統一資源標識符 (URI) 來標識給定的資源並建立連接。建立連接后, HTTP 消息的傳遞方式與 internet

郵件 [RFC5322] 和多用途 internet 郵件擴展 (MIME) [RFC2045] 所使用的格式類似。這些消息包括從客戶端到服務器 的請求以及從服務器到客戶端的響應, 其格式如下:

HTTP-message = <Request> | <Response> ; HTTP/1.1 messages

http 請求和 http 響應使用 RFC 822 的通用消息格式來傳輸所需的數據。此通用郵件格式包括以下四項。

A Start-line
Zero or more header fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body

起始行將具有以下通用語法:

start-line = Request-Line | Status-Line

 

我們將在討論 http 請求和 http 響應消息時分別討論請求行和狀態行。現在, 讓我們看看在請求和響應的情況下開始行的示例:

GET /hello.htm HTTP/1.1 (This is Request-Line sent by the client)
HTTP/1.1 200 OK (This is Status-Line sent by the server)

 

   Header Field

HTTP 標頭字段提供有關請求或響應的必需信息, 或有關在消息正文中發送的對象。有四種類型的 HTTP 消息頭:

通用頭: 這些頭字段對請求和響應消息具有一般適用性。

請求頭: 這些頭字段僅適用於請求消息。

響應頭: 這些頭字段僅適用於響應消息。

實體-頁眉: 這些標頭字段定義元關於實體體, 或者, 如果沒有正文, 則說明請求所標識的資源。

所有 above-mentioned 標頭都遵循相同的通用格式, 並且每個標題字段都由一個后跟冒號 (:) 和字段值的名稱組成, 如下所示:

message-header = field-name ":" [ field-value ]

 

 以下是各種標題字段的示例:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache

Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

 

 

 

    如您對我寫的內容感興趣，可掃描如下二維碼關注我的公眾號，謝謝！！！