說明：

主要使用到“GET”和“POST”。

實(shí)例：

POST /test/tupian/cm HTTP/1.1

分成三部分：

1. POST：HTTP請求方式
2. /test/tupian/cm：請求Web服務(wù)器的目錄地址（或者指令）
3. HTTP/1.1: URI（Uniform Resource Identifier，統(tǒng)一資源標(biāo)識符）及其版本

備注：

在Ajax中，對應(yīng)method屬性設(shè)置。

2、Host

說明：

請求的web服務(wù)器域名地址

3、User-Agent

說明：

HTTP客戶端運(yùn)行的瀏覽器類型的詳細(xì)信息。通過該頭部信息，web服務(wù)器可以判斷到當(dāng)前HTTP請求的客戶端瀏覽器類別。

實(shí)例：

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

4、Accept

說明：

指定客戶端能夠接收的內(nèi)容類型，內(nèi)容類型中的先后次序表示客戶端接收的先后次序。

例如：

Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

備注：

在Prototyp（1.5）的Ajax代碼封裝中，將Accept默認(rèn)設(shè)置為“text/javascript, text/html, application/xml, text/xml, */*”。這是因?yàn)锳jax默認(rèn)獲取服務(wù)器返回的Json數(shù)據(jù)模式。

在Ajax代碼中，可以使用XMLHttpRequest 對象中setRequestHeader函數(shù)方法來動(dòng)態(tài)設(shè)置這些Header信息。

5、Accept-Language

說明：

指定HTTP客戶端瀏覽器用來展示返回信息所優(yōu)先選擇的語言。

實(shí)例：

Accept-Language: zh-cn,zh;q=0.5

這里默認(rèn)為中文。

6、Accept-Encoding

說明：

指定客戶端瀏覽器可以支持的web服務(wù)器返回內(nèi)容壓縮編碼類型。表示允許服務(wù)器在將輸出內(nèi)容發(fā)送到客戶端以前進(jìn)行壓縮，以節(jié)約帶寬。而這里設(shè)置的就是客戶端瀏覽器所能夠支持的返回壓縮格式。

實(shí)例：

Accept-Encoding: gzip,deflate

備注：

其實(shí)在百度很多產(chǎn)品線中，apache在給客戶端返回頁面數(shù)據(jù)之前，將數(shù)據(jù)以gzip格式進(jìn)行壓縮。

7、Accept-Charset

說明：

瀏覽器可以接受的字符編碼集。

實(shí)例：

Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7

8、Content-Type

說明：

顯示此HTTP請求提交的內(nèi)容類型。一般只有post提交時(shí)才需要設(shè)置該屬性。

實(shí)例：

Content-type: application/x-www-form-urlencoded;charset:UTF-8

有關(guān)Content-Type屬性值可以如下兩種編碼類型：

（1）“application/x-www-form-urlencoded”： 表單數(shù)據(jù)向服務(wù)器提交時(shí)所采用的編碼類型，默認(rèn)的缺省值就是“application/x-www-form-urlencoded”。 然而，在向服務(wù)器發(fā)送大量的文本、包含非ASCII字符的文本或二進(jìn)制數(shù)據(jù)時(shí)這種編碼方式效率很低。

（2）“multipart/form-data”： 在文件上載時(shí)，所使用的編碼類型應(yīng)當(dāng)是“multipart/form-data”，它既可以發(fā)送文本數(shù)據(jù)，也支持二進(jìn)制數(shù)據(jù)上載。

當(dāng)提交為單單數(shù)據(jù)時(shí)，可以使用“application/x-www-form-urlencoded”；當(dāng)提交的是文件時(shí)，就需要使用“multipart/form-data”編碼類型。

在Content-Type屬性當(dāng)中還是指定提交內(nèi)容的charset字符編碼。一般不進(jìn)行設(shè)置，它只是告訴web服務(wù)器post提交的數(shù)據(jù)采用的何種字符編碼。

一般在開發(fā)過程，是由前端工程與后端UI工程師商量好使用什么字符編碼格式來post提交的，然后后端ui工程師按照固定的字符編碼來解析提交的數(shù)據(jù)。所以這里設(shè)置的charset沒有多大作用。

9、Connection

說明：

表示是否需要持久連接。如果web服務(wù)器端看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認(rèn)進(jìn)行持久連接），它就可以利用持久連接的優(yōu)點(diǎn)，當(dāng)頁面包含多個(gè)元素時(shí)（例如Applet，圖片），顯著地減少下載所需要的時(shí)間。要實(shí)現(xiàn)這一點(diǎn)， web服務(wù)器需要在返回給客戶端HTTP頭信息中發(fā)送一個(gè)Content-Length（返回信息正文的長度）頭，最簡單的實(shí)現(xiàn)方法是：先把內(nèi)容寫入ByteArrayOutputStream，然 后在正式寫出內(nèi)容之前計(jì)算它的大小。

實(shí)例：

Connection: keep-alive

10、Keep-Alive

說明：

顯示此HTTP連接的Keep-Alive時(shí)間。使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時(shí)，Keep-Alive功能避免了建立或者重新建立連接。

以前HTTP請求是一站式連接，從HTTP/1.1協(xié)議之后，就有了長連接，即在規(guī)定的Keep-Alive時(shí)間內(nèi)，連接是不會(huì)斷開的。

實(shí)例：

Keep-Alive: 300

11、cookie

說明：

HTTP請求發(fā)送時(shí)，會(huì)把保存在該請求域名下的所有cookie值一起發(fā)送給web服務(wù)器。

12、Referer

說明：

包含一個(gè)URL，用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面

Responses 部分

到此這篇關(guān)于HTTP中header頭部信息詳解的文章就介紹到這了,更多相關(guān)HTTP中header頭部信息內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！