http协议（二）
2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
2.?協(xié)議詳解篇
2.1?HTTP/1.0和HTTP/1.1的比較
RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。
筆者在blog上提供了這兩個RFC中文版的下載地址。
RFC1945下載地址：
http://www.blogjava.net/Files/amigoxie/RFC1945（HTTP）中文版.rar
RFC2616下載地址：
http://www.blogjava.net/Files/amigoxie/RFC2616（HTTP）中文版.rar
2.1.1建立連接方面
HTTP/1.0?每次請求都需要建立新的TCP連接，連接不能復(fù)用。HTTP/1.1?新的請求可以在上次請求建立的TCP連接之上發(fā)送，連接可以復(fù)用。優(yōu)點是減少重復(fù)進(jìn)行TCP三次握手的開銷，提高效率。
注意：在同一個TCP連接中，新的請求需要等上次請求收到響應(yīng)后，才能發(fā)送。
2.1.2?Host域
HTTP1.1在Request消息頭里頭多了一個Host域, HTTP1.0則沒有這個域。
Eg：
????GET?/pub/WWW/TheProject.html?HTTP/1.1
????Host:?www.w3.org
????可能HTTP1.0的時候認(rèn)為，建立TCP連接的時候已經(jīng)指定了IP地址，這個IP地址上只有一個host。
2.1.3日期時間戳
(接收方向)
無論是HTTP1.0還是HTTP1.1，都要能解析下面三種date/time stamp：
Sun,?06?Nov?1994?08:49:37?GMT?;?RFC?822,?updated?by?RFC?1123
Sunday,?06-Nov-94?08:49:37?GMT?;?RFC?850,?obsoleted?by?RFC?1036
Sun?Nov?6?08:49:37?1994???????;?ANSI?C's?asctime()?format
?????? (發(fā)送方向)
HTTP1.0要求不能生成第三種asctime格式的date/time stamp；
HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。
2.1.4狀態(tài)響應(yīng)碼
狀態(tài)響應(yīng)碼100 (Continue)?狀態(tài)代碼的使用，允許客戶端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發(fā)request body。
客戶端在Request頭部中包含
Expect:?100-continue
?????? Server看到之后呢如果回100 (Continue)?這個狀態(tài)代碼，客戶端就繼續(xù)發(fā)request body。這個是HTTP1.1才有的。
另外在HTTP/1.1中還增加了101、203、205等等性狀態(tài)響應(yīng)碼
2.1.5請求方式
HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法.
?????? Method???????? = "OPTIONS"??????????????? ; Section 9.2
????????????????????? | "GET"??????????????????? ; Section 9.3
????????????????????? | "HEAD"?????????????????? ; Section 9.4
????????????????????? | "POST"?????????????????? ; Section 9.5
????????????????????? | "PUT"??????????????????? ; Section 9.6
????????????????????? | "DELETE"???????????????? ; Section 9.7
????????????????????? | "TRACE"????????????????? ; Section 9.8
????????????????????? | "CONNECT"??????????????? ; Section 9.9
????????????????????? | extension-method
?????? extension-method = token
2.2?HTTP請求消息
2.2.1請求消息格式
請求消息格式如下所示：
請求行
通用信息頭|請求頭|實體頭
CRLF(回車換行)
實體內(nèi)容
其中“請求行”為：請求行?=?方法?[空格]?請求URI [空格]?版本號?[回車換行]
請求行實例：
Eg1：
GET?/index.html?HTTP/1.1
?????? Eg2：
POST?http://192.168.2.217:8080/index.jsp HTTP/1.1
HTTP請求消息實例：
GET?/hello.htm?HTTP/1.1
Accept:?*/*
Accept-Language:?zh-cn
Accept-Encoding:?gzip,?deflate
If-Modified-Since:?Wed,?17?Oct?2007?02:15:55?GMT
If-None-Match:?W/"158-1192587355000"
User-Agent:?Mozilla/4.0?(compatible;?MSIE?6.0;?Windows?NT?5.1;?SV1)
Host:?192.168.2.162:8080
Connection:?Keep-Alive
2.2.2請求方法
?????? HTTP的請求方法包括如下幾種：
? ? ? GET
? ? ?POST
? ? ?HEAD
? ? ?PUT
? ? ?DELETE
? ? OPTIONS
? ? ? TRACE
? ? ? CONNECT
2.3 HTTP響應(yīng)消息
2.3.1響應(yīng)消息格式
HTTP響應(yīng)消息的格式如下所示：
狀態(tài)行
通用信息頭|響應(yīng)頭|實體頭
CRLF
實體內(nèi)容
其中：狀態(tài)行?=?版本號?[空格]?狀態(tài)碼?[空格]?原因?[回車換行]
狀態(tài)行舉例：
Eg1：
HTTP/1.0?200?OK?
????? Eg2：
HTTP/1.1?400?Bad?Request
???? HTTP響應(yīng)消息實例如下所示：
HTTP/1.1?200?OK
ETag:?W/"158-1192590101000"
Last-Modified:?Wed,?17?Oct?2007?03:01:41?GMT
Content-Type:?text/html
Content-Length:?158
Date:?Wed,?17?Oct?2007?03:01:59?GMT
Server:?Apache-Coyote/1.1
2.3.2?http的狀態(tài)響應(yīng)碼
2.3.2.1 ?1**：請求收到，繼續(xù)處理
100——客戶必須繼續(xù)發(fā)出請求
101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本
2.3.2.2 ?2**：操作成功收到，分析、接受
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息為空
205——服務(wù)器完成了請求，用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過的文件
206——服務(wù)器已經(jīng)完成了部分用戶的GET請求
2.3.2.3 ?3**：完成此請求必須進(jìn)一步處理
300——請求的資源可在多處得到
301——刪除請求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù)
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化
305——請求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用
307——申明請求的資源臨時性刪除
2.3.2.4 ?4**：請求包含一個錯誤語法或不能完成
400——錯誤請求，如語法錯誤
401——未授權(quán)
HTTP 401.1 -?未授權(quán)：登錄失敗
HTTP 401.2 -?未授權(quán)：服務(wù)器配置問ti導(dǎo)致登錄失敗
HTTP 401.3 - ACL?禁止訪問資源
HTTP 401.4 -?未授權(quán)：授權(quán)被篩選器拒絕
HTTP 401.5 -?未授權(quán)：ISAPI?或?CGI?授權(quán)失敗
402——保留有效ChargeTo頭響應(yīng)
403——禁止訪問
HTTP 403.1?禁止訪問：禁止可執(zhí)行訪問
HTTP 403.2 -?禁止訪問：禁止讀訪問
HTTP 403.3 -?禁止訪問：禁止寫訪問
HTTP 403.4 -?禁止訪問：要求?SSL
HTTP 403.5 -?禁止訪問：要求?SSL 128
HTTP 403.6 -?禁止訪問：IP?地址被拒絕
HTTP 403.7 -?禁止訪問：要求客戶證書
HTTP 403.8 -?禁止訪問：禁止站點訪問
HTTP 403.9 -?禁止訪問：連接的用戶過多
HTTP 403.10 -?禁止訪問：配置無效
HTTP 403.11 -?禁止訪問：密碼更改
HTTP 403.12 -?禁止訪問：映射器拒絕訪問
HTTP 403.13 -?禁止訪問：客戶證書已被吊銷
HTTP 403.15 -?禁止訪問：客戶訪問許可過多
HTTP 403.16 -?禁止訪問：客戶證書不可信或者無效
HTTP 403.17 -?禁止訪問：客戶證書已經(jīng)到期或者尚未生效
404——沒有發(fā)現(xiàn)文件、查詢或URl
405——用戶在Request-Line字段定義的方法不允許
406——根據(jù)用戶發(fā)送的Accept拖，請求資源不可訪問
407——類似401，用戶必須首先在代理服務(wù)器上得到授權(quán)
408——客戶端沒有在用戶指定的餓時間內(nèi)完成請求
409——對當(dāng)前資源狀態(tài)，請求不能完成
410——服務(wù)器上不再有此資源且無進(jìn)一步的參考地址
411——服務(wù)器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當(dāng)前請求中錯誤
413——請求的資源大于服務(wù)器允許的大小
414——請求的資源URL長于服務(wù)器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當(dāng)前請求資源范圍內(nèi)沒有range指示值，請求也不包含If-Range請求頭字段
417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級服務(wù)器不能滿足請求長。
2.3.2.5 ?5**：服務(wù)器執(zhí)行一個完全有效請求失敗
HTTP 500 -?內(nèi)部服務(wù)器錯誤
HTTP 500.100 -?內(nèi)部服務(wù)器錯誤?- ASP?錯誤
HTTP 500-11?服務(wù)器關(guān)閉
HTTP 500-12?應(yīng)用程序重新啟動
HTTP 500-13 -?服務(wù)器太忙
HTTP 500-14 -?應(yīng)用程序無效
HTTP 500-15 -?不允許請求?global.asa
Error 501 -?未實現(xiàn)
HTTP 502 -?網(wǎng)關(guān)錯誤
2.4?使用telnet進(jìn)行http測試
???????在Windows下，可使用命令窗口進(jìn)行http簡單測試。
???????輸入cmd進(jìn)入命令窗口，在命令行鍵入如下命令后按回車：
telnet?www.baidu.com?80
???????而后在窗口中按下“Ctrl+]”后按回車可讓返回結(jié)果回顯。
接著開始發(fā)請求消息，例如發(fā)送如下請求消息請求baidu的首頁消息，使用的HTTP協(xié)議為HTTP/1.1：
GET?/index.html?HTTP/1.1
???注意：copy如上的消息到命令窗口后需要按兩個回車換行才能得到響應(yīng)的消息，第一個回車換行是在命令后鍵入回車換行，是HTTP協(xié)議要求的。第二個是確認(rèn)輸入，發(fā)送請求。
可看到返回了200 OK的消息，如下圖所示：
???????可看到，當(dāng)采用HTTP/1.1時，連接不是在請求結(jié)束后就斷開的。若采用HTTP1.0，在命令窗口鍵入：
GET?/index.html?HTTP/1.0
??????此時可以看到請求結(jié)束之后馬上斷開。
???????讀者還可以嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入如下信息：
GET?/index.html?HTTP/1.1
connection:?close
Host:?www.baidu.com
2.5?常用的請求方式
???????常用的請求方式是GET和POST.
l?????????GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數(shù)據(jù)產(chǎn)生過程，那么最終要在響應(yīng)實體中返回的是處理過程的結(jié)果所指向的資源，而不是處理過程的描述。
l?????????POST方式：用來向目的服務(wù)器發(fā)出請求，要求它接受被附在請求后的實體，并把它當(dāng)作請求隊列中請求URI所指定資源的附加新子項，Post被設(shè)計成用統(tǒng)一的方法實現(xiàn)下列功能：
1：對現(xiàn)有資源的解釋；
2：向dian子公告欄、新聞組、郵件列表或類似討論組發(fā)信息；
3：提交數(shù)據(jù)塊；
4：通過附加操作來擴(kuò)展數(shù)據(jù)庫?。
從上面描述可以看出，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實體中。
GET與POST方法有以下區(qū)別：
（1）???在客戶端，Get方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到；POST方式，數(shù)據(jù)放置在HTML HEADER內(nèi)提交。
（2）?? GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。
（3）???安全性問ti。正如在（1）中提到，使用?Get?的時候，參數(shù)會顯示在地址欄上，而?Post?不會。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用?get；如果用戶輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用?post為好。
（4）???安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等 的意味著對同一?URL?的多個請求應(yīng)該返回同樣的結(jié)果。完整的定義并不像看起來那樣嚴(yán)格。換句話說，GET?請求一般不應(yīng)產(chǎn)生副作用。從根本上講，其目 標(biāo)是當(dāng)用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞?wù)军c的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被 認(rèn)為是安全的和冪等的，因為它總是返回當(dāng)前的新聞。反之亦然。POST?請求就不那么輕松了。POST?表示可能改變服務(wù)器上的資源的請求。仍然以新聞?wù)?點為例，讀者對文章的注解應(yīng)該通過?POST?請求實現(xiàn)，因為在注解提交之后站點已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）。
?
2.6?請求頭
HTTP最常見的請求頭如下：
l?????????Accept：瀏覽器可接受的MIME類型；
l?????????Accept-Charset：瀏覽器可接受的字符集；
l?????????Accept-Encoding：瀏覽器能夠進(jìn)行解碼的數(shù)據(jù)編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間；
l?????????Accept-Language：瀏覽器所希望的語言種類，當(dāng)服務(wù)器能夠提供一種以上的語言版本時要用到；
l?????????Authorization：授權(quán)信息，通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中；
l?????????Connection：表示 是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認(rèn)進(jìn)行持久連接），它就可以利用持久連接的優(yōu)點，當(dāng)頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現(xiàn)這一 點，Servlet需要在應(yīng)答中發(fā)送一個Content-Length頭，最簡單的實現(xiàn)方法是：先把內(nèi)容寫入 ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計算它的大小；
l?????????Content-Length：表示請求消息正文的長度；
l?????????Cookie：這是最重要的請求頭信息之一；
l?????????From：請求發(fā)送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它；
l?????????Host：初始URL中的主機和端口；
l?????????If-Modified-Since：只有當(dāng)所請求的內(nèi)容在指定的日期之后又經(jīng)過修改才返回它，否則返回304“Not Modified”應(yīng)答；
l?????????Pragma：指定“no-cache”值表示服務(wù)器必須返回一個刷新后的文檔，即使它是代理服務(wù)器而且已經(jīng)有了頁面的本地拷貝；
l?????????Referer：包含一個URL，用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面。
l?????????User-Agent：瀏覽器類型，如果Servlet返回的內(nèi)容與瀏覽器類型有關(guān)則該值非常有用；
l?????????UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發(fā)送的非標(biāo)準(zhǔn)的請求頭，表示屏幕大小、顏色深度、操作系統(tǒng)和CPU類型。
2.7?響應(yīng)頭
HTTP最常見的響應(yīng)頭如下所示：
l?????????Allow：服務(wù)器支持哪些請求方法（如GET、POST等）；
l?????????Content-Encoding： 文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔 的下載時間。Java的GZIPOutputStream可以很方便地進(jìn)行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過查看Accept-Encoding頭（即request.getHeader("Accept- Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面；
l?????????Content-Length： 表示內(nèi)容長度。只有當(dāng)瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過 byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容；
l?????????Content-Type：?表 示后面的文檔屬于什么MIME類型。Servlet默認(rèn)為text/plain，但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置 Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。?可在web.xml文件中 配置擴(kuò)展名和MIME類型的對應(yīng)關(guān)系；
l?????????Date：當(dāng)前的GMT時間。你可以用setDateHeader來設(shè)置這個頭以避免轉(zhuǎn)換時間格式的麻煩；
l?????????Expires：指明應(yīng)該在什么時候認(rèn)為文檔已經(jīng)過期，從而不再緩存它。
l?????????Last-Modified： 文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文 檔才會返回，否則返回一個304（Not Modified）狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置；
l?????????Location：表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設(shè)置狀態(tài)代碼為302；
l?????????Refresh：表示瀏覽器應(yīng)該在多少時間之后刷新文檔，以秒計。除了刷新當(dāng)前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設(shè)置HTML頁面HEAD區(qū)的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"> 實現(xiàn)，這是因為，自動刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設(shè)置 Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續(xù) 刷新要求每次都發(fā)送一個Refresh頭，而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個擴(kuò)展，但Netscape和IE都支持它。
2.8實體頭
實體頭用坐實體內(nèi)容的元信息，描述了實體內(nèi)容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數(shù)據(jù)有效性等。
l?????????Allow：GET,POST
l?????????Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5?響應(yīng)頭”；
l?????????Content-Language：內(nèi)容的語言類型，例如：zh-cn；
l?????????Content-Length：表示內(nèi)容長度，eg：80，可參考“2.5響應(yīng)頭”；
l?????????Content-Location：表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n，例如：http://www.dfdf.org/dfdf.html，可參考“2.5響應(yīng)頭”；
l?????????Content-MD5：MD5?實 體的一種MD5摘要，用作校驗和。發(fā)送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標(biāo)中傳遞的值進(jìn)行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；
l?????????Content-Range：隨部分實體一同發(fā)送；標(biāo)明被插入字節(jié)的低位與高位字節(jié)偏移，也標(biāo)明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898
l?????????Content-Type：標(biāo)明發(fā)送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312???????主類型/子類型；
l?????????Expires：為0證明不緩存；
l?????????Last-Modified：WEB?服務(wù)器認(rèn)為對象的最后修改時間，比如文件的最后修改時間，動態(tài)頁面的最后產(chǎn)生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.
2.9擴(kuò)展頭
在HTTP消息中，也可以使用一些再HTTP1.1正式規(guī)范里沒有定義的頭字段，這些頭字段統(tǒng)稱為自定義的HTTP頭或者擴(kuò)展頭，他們通常被當(dāng)作是一種實體頭處理。
現(xiàn)在流行的瀏覽器實際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個常用的擴(kuò)展頭字段。
l?????????Refresh：1;url=http://www.dfdf.org? //過1秒跳轉(zhuǎn)到指定位置；
l?????????Content-Disposition：頭字段,可參考“2.5響應(yīng)頭”；
l?????????Content-Type：WEB?服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型。
eg1：Content-Type：application/xml?；
eg2：applicaiton/octet-stream；
Content-Disposition：attachment; filename=aaa.zip。
??附錄：參考資料
《HTTP1.1和HTTP1.0的區(qū)別》：
http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx
《HTTP請求（GET和POST區(qū)別）和響應(yīng)》：
http://www.blogjava.net/honeybee/articles/164008.html
?
《HTTP請求頭概述_百度知道》：
http://zhidao.baidu.com/question/32517427.html
《實體頭和擴(kuò)展頭》：
http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html
轉(zhuǎn)載于:https://my.oschina.net/kimspan/blog/597203
總結(jié)
- 上一篇： DButils数据库升级不丢失数据
- 下一篇： 变量的存储类别以及作用空间