HTTP請求和MIME介紹

HTTP請求和MIME介紹

HTTP請求由三部分組成，分別是：

請求行，消息報頭，請求正文。

請求行(格式)：

Method Request-URI HTTP-Version CRLF

Method:方法。

• GET                   請求獲取由Request-URI所標識的資源。
• POST                在Request-URI所標識的資源后附加新的數據。
• HEAD               請求獲取由Request-URI所標識的資源的響應消息報頭。
• PUT                  請求服務器存儲一個資源，並用Request-URI作為其標識。
• DELETE           請求服務器刪除由Request-URI所標識的資源。
• TRACE             請求服務器回送收到的請求信息，主要用語測試或診斷。
• CONNECT       保留將來使用。
• OPTIONS         請求查詢服務器的性能，或查詢與資源相關的選項和需求。
• Request-URI     統一資源標識。
• HTTP-Version    HTTP的版本。
• CRLF                 回車換行。(/r/n)

 

例：

GET /form.html HTTP/1.1 /r/n
HTTP響應

在接收和解釋請求消息后，服務器會返回一個HTTP響應消息。

與HTTP請求類似，HTTP響應也是三個部分組成，分別是：

狀態行、消息報頭、響應正文。

狀態行：

狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。

格式:    HTTP-Version Status-Code Reason-Phrase CRLF

例如:    HTTP/1.1 200 OK /r/n

狀態代碼：

狀態代碼由3位數字組成，表示請求是否被理解或被滿足。

狀態描述：

狀態描述給出了關於狀態代碼的簡短的文字描述。

狀態代碼的第一個數字定義了響應的類別，后面兩位沒有具體的分類。

第一個數字有五種可能的取值：

• - 1xx:   指示信息—表示請求已接收，繼續處理。
• - 2xx:   成功—表示請求已經被成功接收、理解、接受。
• - 3xx:   重定向—要完成請求必須進行更進一步的操作。
• - 4xx:   客戶端錯誤—請求有語法錯誤或請求無法實現。
• - 5xx: 服務器端錯誤—服務器未能實現合法的請求。

         狀態代碼 狀態描述    說明

•    200      OK    客戶端請求成功
•    400      Bad Request   由於客戶端請求有語法錯誤，不能被服務器所理解。
•    401      Unauthonzed   請求未經授權。這個狀態代碼必須和WWW-Authenticate報頭域一起使用
•    403      Forbidden   服務器收到請求，但是拒絕提供服務。服務器通常會在響應正文中給出不提供服務的原因
•    404      Not Found   請求的資源不存在，例如，輸入了錯誤的URL。
•    500     Internal Server Error 服務器發生不可預期的錯誤，導致無法完成客戶端的請求。
•    503      Service Unavailable   服務器當前不能夠處理客戶端的請求，在一段時間之后，服務器可能會恢復正常。

HTTP消息

HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行，消息報頭(可選的)，空行(只有CTLF的行)，消息正文(可選的)組成。

對於請求消息，開始行就是請求行。

對於響應消息，開始行就是狀態行。

消息報頭

HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。

每一個報頭域都是由(名字＋":"＋空格＋值)組成,消息報頭域的名字是大小寫無關的。

普通報頭：

   在普通報頭中，有少數報頭域應用於所有的請求和響應消息，但並不用於被傳輸的實體，這些報頭域只用於傳輸的消息。

常用的普通報頭域：Cache-Control,Date,Connection,Pragma.

請求報頭：

   請求報頭允許客戶端向服務器端傳遞該請求的附加信息以及客戶端自身的信息。

常用的請求報頭域：

   Accept

      Accept請求報頭域用語指定客戶端接受哪些類型的信息。例如：Accept: image/gif,表明客戶端希望接受GIF圖象格式的資源；Accept: text/html,表明客戶端希望接受html文本。

   Accept-Charset

      Accept-Charset請求報頭域用於指定客戶端接受的字符集。例如：Accept-Charset: ios-8859-1,gb2312。如果在請求消息中沒有設置這個域，缺省是任何字符集都可以接受。

   Accept-Encoding

      Accept-Encoding請求報頭域類似Accept，但是它是用於指定可接受的內容編碼。例如：Accept-Encoding: gzip,deflate。如果請求消息中沒有設置這個域，服務器假定客戶端對各種內容編碼都可接受。

   Accept-Language

      Accept-Language請求報頭域類似於Accept,但是它是用於指定一種自然語言。例如：Accept-Language: zh-cn。如果請求消息中沒有設置這個域，服務器假定客戶端對各種語言都可接受。

   Authorization

      Authorization請求報頭域主要用於證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401(未授權)，可以發送一個包含Authorization請求報頭域的請求，要服務器對其進行驗證。

   Host

      Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它通常是從HTTP URL中提取出來的。

例如:http://www.sunxin.org/index.html。瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：Host: www.sunxin.org

后面沒有跟端口號，表明使用的是缺省端口號80，如果端口號不是80，那么就要在主機名后面加上一個冒號(":"),然后接上端口號，例如：

Host: www.sunxin.org:8080。   要注意的是，在發送HTTP請求的時候，這個報頭域是必須的。

   User-Agent

      User-Agent允許客戶端將它的操作系統瀏覽器和其他屬性告訴服務器。我們上網登陸論壇的時候，往往看到些歡迎信息，其中列出了你的操作系統的名稱 和版本等等信息。原因是：服務器從User-Agent請求報頭域中獲取的這些信息，自己編寫瀏覽器可以不用這個請求報頭域。服務器就無法得知了。

響應報頭

   響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。

常用的響應報頭域：

   Location

      Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，服務 器端可以發回Location響應報頭后使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源。當我們在JSP中使用重定向語句的時候，服務器 端向客戶端發回的響應報頭中，就會有Location響應報頭域。

   Server

      Server響應報頭域包含了服務器用來處理請求的軟件信息。它和User-Agent請求報頭域是相對應的，前者發送服務器端軟件的信息，后者發送客戶 端軟件(瀏覽器)和操作系統的信息。下面是Server響應報頭域的一個例子：Server: Apache-Coyote/1.1

   WWW-Authenticate

      WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應消息中，這個報頭域和前面講到的Authorization請求報頭域是 相關的，當客戶端收到401響應消息，就要決定是否請求服務器對其進行驗證。如果要求服務器對其進行驗證，就可以發送一個包含了 Authorization報頭域的請求，下面是WWW-Authenticate響應報頭域的一個例子：WWW-Authenticate: Basic realm="Basic Auth Test!"

從這個響應報頭域，可以知道服務器端對我們所請求的資源采用的是基本驗證機制。

實體報頭

   請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成，大多數情況下，實體正文就是請求消息中的請求正文或者響應消息中的響應正 文。但是在發送時，並不是說實體報頭域和實體正文要在一起發送，例如：有些響應可以只包含實體報頭域。實體就好象我們寫的書信，在信中，我們可以寫上標 題，加上頁號等，這部分就相當於是實體報頭域，而我們所寫的書信的內容，就相當於實體正文。前面說講的普通報頭、請求報頭、響應報頭我們可以看成是寫在信 封上的郵編、接收者，發送者等內容。

實體報頭定義了關於實體正文(例如：有無實體正文)和請求所標識的資源的元信息。

所謂元信息，是指描述其他信息的信息。

常用的實體報頭域：

   Content-Encoding

       Content-Encoding實體報頭域被使用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content- Type報頭域中所引用的媒體類型，必須采用相應的解碼機制。Content-Encoding主要用語記錄文檔的壓縮方法，下面是它的一個例子： Content-Encoding: gzip。如果一個實體正文采用了編碼方式存儲，在使用之前就必須進行解碼。

   Content-Language

       Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許用戶遵照自身的首選語言來識別和區分實體。 如果這個實體內容僅僅打算提供給丹麥的閱讀者，那么可以按照如下的方式設置這個實體報頭域：Content-Language: da。

如果沒有指定Content-Language報頭域，那么實體內容將提供給所以語言的閱讀者。

   Content-Length

       Content-Length實體報頭域用於指明正文的長度，以字節方式存儲的十進制數字來表示，也就是一個數字字符占一個字節，用其對應的ASCII碼存儲傳輸。

       要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。

   Content-Type

       Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。例如：

    Content-Type: text/html;charset=ISO-8859-1

    Content-Type: text/html;charset=GB2312

   Last-Modified

       Last-Modified實體報頭域用於指示資源最后的修改日期及時間。

   Expires

       Expires實體報頭域給出響應過期的日期和時間。通常，代理服務器或瀏覽器會緩存一些頁面。當用戶再次訪問這些頁面時，直接從緩存中加載並顯示給用 戶，這樣縮短了響應的時間，減少服務器的負載。為了讓代理服務器或瀏覽器在一段時間后更新頁面，我們可以使用Expires實體報頭域指定頁面過期的時 間。當用戶又一次訪問頁面時，如果Expires報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早(或相同)，那么代理服務器或瀏覽器就 不會再使用緩存的頁面而是從服務器上請求更新的頁面。不過要注意，即使頁面過期了，也並不意味着服務器上的原始資源在此時間之前或之后發生了改變。

       Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式，例如：

    Expires: Thu, 15 Sep 2005 16:00:00 GMT

       HTTP1.1的客戶端和緩存必須將其他非法的日期格式(也包括0)看作已過期。例如，為了讓瀏覽器不要緩存頁面，我們也可以利用Expires實體報頭 域，設置它的值為0，如下(JSP)：response.setDateHeader("Expires",0); 

什么是MIME

MIME, 全稱為“Multipurpose Internet Mail Extensions”, 比較確切的中文名稱為“多用途互聯網郵件擴展”。它是當前廣泛應用的一種電子郵件技術規范，基本內容定義於RFC 2045-2049

什么是MIME類型?-在把輸出結果傳送到瀏覽器上的時候，瀏覽器必須啟動適當的應用程序來處理這個輸出文檔。這可以通過多種類型MIME（多功能網際郵件擴充協議）來完成。在HTTP中，MIME類型被定義在Content-Type header中。

例 如，架設你要傳送一個Microsoft Excel文件到客戶端。那么這時的MIME類型就是“application/vnd.ms-excel”。 在大多數實際情況中，這個文件然后將傳送給 Execl來處理（假設我們設定Execl為處理特殊MIME類型的應用程序）。在ASP中，設定MIME類 型的方法是通過Response對象的 ContentType屬性。

多媒體文件格式MIME

最早的HTTP協議中，並沒有附加的數據類型信息，所有傳送的數據都被客戶程序解釋為超文本標記語言HTML 文檔，而為了支持多媒體數據類型，HTTP協議中就使用了附加在文檔之前的MIME數據類型信息來標識數據類型。

MIME意為多目Internet郵件擴展，它設計的最初目的是為了在發送電子郵件時附加多媒體數據，讓郵件客戶程序能根據其類型進行處理。然而當它被HTTP協議支持之后，它的意義就更為顯著了。它使得HTTP傳輸的不僅是普通的文本，而變得豐富多彩。

每個MIME類型由兩部分組成，前面是數據的大類別，例如聲音audio、圖象image等，后面定義具體的種類。

常見的MIME類型

超文本標記語言文本 .html,.html text/html

普通文本 .txt text/plain

RTF文本 .rtf application/rtf

GIF圖形 .gif image/gif

JPEG圖形 .ipeg,.jpg image/jpeg

au聲音文件 .au audio/basic

MIDI音樂文件 mid,.midi audio/midi,audio/x-midi

RealAudio音樂文件 .ra, .ram audio/x-pn-realaudio

MPEG文件 .mpg,.mpeg video/mpeg

AVI文件 .avi video/x-msvideo

GZIP文件 .gz application/x-gzip

TAR文件 .tar application/x-tar

Internet 中有一個專門組織IANA來確認標准的MIME類型，但Internet發展的太快，很多應用程序等不及IANA來確認他們使用的 MIME類型為標准類 型。因此他們使用在類別中以x-開頭的方法標識這個類別還沒有成為標准，例如：x-gzip，x-tar等。事實上這些類型運用的很廣泛，已經成為了事實 標准。只要客戶機和服務器共同承認這個MIME類型，即使它是不標准的類型也沒有關系，客戶程序就能根據MIME類型，采用具體的處理手段來處理數據。而 Web服務器和瀏覽器（包括操作系統）中，缺省都設置了標准的和常見的MIME類型，只有對於不常見的 MIME類型，才需要同時設置服務器和客戶瀏覽 器，以進行識別。

由於MIME類型與文檔的后綴相關，因此服務器使用文檔的后綴來區分不同文件的MIME類型，服務器中必須定義文檔后綴 和MIME類型之間的對應關系。而客戶程序從服務器上接收數據的時候，它只是從服務器接受數據流，並不了解文檔的名字，因此服務器必須使用附加信息來告訴 客戶程序數據的MIME類型。服務器在發送真正的數據之前，就要先發送標志數據的MIME類型的信息，這個信息使用Content-type關鍵字進行定 義，例如對於HTML文檔，服務器將首先發送以下兩行MIME標識信息,這個標識並不是真正的數據文件的一部分。

Content-type: text/html

注意，第二行為一個空行，這是必須的，使用這個空行的目的是將MIME信息與真正的數據內容分隔開。