http 原理

工作流程


一次HTTP操作稱為一個事務(wù),其工作過程可分為四步:

1)首先客戶機與服務(wù)器需要建立連接。只要單擊某個超級鏈接,HTTP的工作開始。

2)建立連接后,客戶機發(fā)送一個請求給服務(wù)器,請求方式的格式為:統(tǒng)一資源標(biāo)識符(URL)、協(xié)議版本號,后邊是MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。

3)服務(wù)器接到請求后,給予相應(yīng)的響應(yīng)信息,其格式為一個狀態(tài)行,包括信息的協(xié)議版本號、一個成功或錯誤的代碼,后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。

4)客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上,然后客戶機與服務(wù)器斷開連接。

如果在以上過程中的某一步出現(xiàn)錯誤,那么產(chǎn)生錯誤的信息將返回到客戶端,有顯示屏輸出。對于用戶來說,這些過程是由HTTP自己完成的,用戶只要用鼠標(biāo)點擊,等待信息顯示就可以了。

頭域

每個頭域由一個域名,冒號(:)和域值三部分組成。域名是大小寫無關(guān)的,域值前可以添加任何數(shù)量的空格符,頭域可以被擴展為多行,在每行開始處,使用至少一個空格或制表符。

1、請求信息:

發(fā)出的請求信息格式如下:●請求行,例如GET /images/logo.gif HTTP/1.1,表示從/images目錄下請求logo.gif這個文件。●(請求)頭,例如Accept-Language: en●空行●可選的消息體 請求行和標(biāo)題必須以作為結(jié)尾(也就是,回車然后換行)。空行內(nèi)必須只有而無其他空格。在HTTP/1.1協(xié)議中,所有的請求頭,除post外,都是可選的。

三個部分分別是:請求行、消息報頭、請求正文。

2、請求方法

HTTP/1.1協(xié)議中共定義了八種方法(有時也叫“動作”)來表明Request-URI指定的資源的不同操作方式:

OPTIONS - 返回服務(wù)器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務(wù)器發(fā)送'*'的請求來測試服務(wù)器的功能性。

HEAD- 向服務(wù)器索要與GET請求相一致的響應(yīng),只不過響應(yīng)體將不會被返回。這一方法可以在不必傳輸整個響應(yīng)內(nèi)容的情況下,就可以獲取包含在響應(yīng)消息頭中的元信息。該方法常用于測試超鏈接的有效性,是否可以訪問,以及最近是否更新。

GET - 向特定的資源發(fā)出請求。注意:GET方法不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中,例如在web app.中。其中一個原因是GET可能會被網(wǎng)絡(luò)蜘蛛等隨意訪問。

POST - 向指定資源提交數(shù)據(jù)進(jìn)行處理請求(例如提交表單或者上傳文件)。數(shù)據(jù)被包含在請求體中。POST請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。

PUT - 向指定資源位置上傳其最新內(nèi)容。

DELETE - 請求服務(wù)器刪除Request-URI所標(biāo)識的資源。

TRACE- 回顯服務(wù)器收到的請求,主要用于測試或診斷。

CONNECT - HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

PATCH - 用來將局部修改應(yīng)用于某一資源,添加于規(guī)范RFC5789。

方法名稱是區(qū)分大小寫的。當(dāng)某個請求所針對的資源不支持對應(yīng)的請求方法的時候,服務(wù)器應(yīng)當(dāng)返回狀態(tài)碼405(Method Not Allowed);當(dāng)服務(wù)器不認(rèn)識或者不支持對應(yīng)的請求方法的時候,應(yīng)當(dāng)返回狀態(tài)碼501(Not Implemented)。

HTTP服務(wù)器至少應(yīng)該實現(xiàn)GET和HEAD方法,其他方法都是可選的。此外,除了上述方法,特定的HTTP服務(wù)器還能夠擴展自定義的方法。

3、響應(yīng)消息

客戶端向服務(wù)器發(fā)送一個請求,服務(wù)器以一個狀態(tài)行作為響應(yīng),響應(yīng)的內(nèi)容包括:消息協(xié)議的版本、成功或者錯誤編碼、服務(wù)器信息、實體元信息以及必要的實體內(nèi)容。根據(jù)響應(yīng)類別的類別,服務(wù)器響應(yīng)里可以含實體內(nèi)容,但不是所有的響應(yīng)都有實體內(nèi)容。

響應(yīng)頭第一行也稱為狀態(tài)行,格式如下(下圖中紅線標(biāo)出的那行):

HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

HTTP- Version表示HTTP版本,例如為HTTP/1.1。Status- Code是結(jié)果代碼,用三個數(shù)字表示。Reason-Phrase是個簡單的文本描述,解釋Status-Code的具體原因。Status-Code用于機器自動識別,Reason-Phrase用于人工理解。Status-Code的第一個數(shù)字代表響應(yīng)類別,可能取5個不同的值。后兩個數(shù)字沒有分類作用。Status-Code的第一個數(shù)字代表響應(yīng)的類別,后續(xù)兩位描述在該類響應(yīng)下發(fā)生的具體狀況,具體請參見:HTTP狀態(tài)碼 。

三個部分分別是:狀態(tài)行、消息報頭、響應(yīng)正文。

無論你何時瀏覽一個網(wǎng)頁,你的電腦都會通過一個使用HTTP協(xié)議的服務(wù)器來獲取所請求的數(shù)據(jù)。在你請求的網(wǎng)頁顯示在瀏覽器之前,支配網(wǎng)頁的網(wǎng)站服務(wù)器會返回一個包含有狀態(tài)碼的HTTP頭文件。這個狀態(tài)碼提供了有關(guān)所請求網(wǎng)頁的相關(guān)條件信息。如果一切正常,一個標(biāo)準(zhǔn)網(wǎng)頁會收到一條諸如200的狀態(tài)碼。當(dāng)然我們的目的不是去研究200響應(yīng)碼,而是去探討那些代表出現(xiàn)錯誤信息的服務(wù)器頭文件響應(yīng)碼,例如表示“未找到指定網(wǎng)頁”的404碼。

4、響應(yīng)頭域

服務(wù)器需要傳遞許多附加信息,這些信息不能全放在狀態(tài)行里。因此,需要另行定義響應(yīng)頭域,用來描述這些附加信息。響應(yīng)頭域主要描述服務(wù)器的信息和Request-URI的信息。

5、HTTP常見的請求頭(在HTTP/1.1 協(xié)議中,所有的請求頭,除Host外,都是可選的)

If-Modified-Since:把瀏覽器端緩存頁面的最后修改時間發(fā)送到服務(wù)器去,服務(wù)器會把這個時間與服務(wù)器上實際文件的最后修改時間進(jìn)行對比。如果時間一致,那么返回304,客戶端就直接使用本地緩存文件。如果時間不一致,就會返回200和新的文件內(nèi)容。客戶端接到之后,會丟棄舊文件,把新文件緩存起來,并顯示在瀏覽器中。

例如:If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

If-None-Match:If-None-Match和ETag一起工作,工作原理是在HTTP Response中添加ETag信息。 當(dāng)用戶再次請求該資源時,將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務(wù)器驗證資源的ETag沒有改變(該資源沒有更新),將返回一個304狀態(tài)告訴客戶端使用本地緩存文件。否則將返回200狀態(tài)和新的資源和Etag.? 使用這樣的機制將提高網(wǎng)站的性能。例如: If-None-Match: "03f2b33c0bfcc1:0"。

Pragma:指定“no-cache”值表示服務(wù)器必須返回一個刷新后的文檔,即使它是代理服務(wù)器而且已經(jīng)有了頁面的本地拷貝;在HTTP/1.1版本中,它和Cache-Control:no-cache作用一模一樣。Pargma只有一個用法, 例如: Pragma: no-cache

注意: 在HTTP/1.0版本中,只實現(xiàn)了Pragema:no-cache, 沒有實現(xiàn)Cache-Control

Cache-Control:指定請求和響應(yīng)遵循的緩存機制。緩存指令是單向的(響應(yīng)中出現(xiàn)的緩存指令在請求中未必會出現(xiàn)),且是獨立的(在請求消息或響應(yīng)消息中設(shè)置Cache-Control并不會修改另一個消息處理過程中的緩存處理過程)。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached,響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。

Cache-Control:Public 可以被任何緩存所緩存

Cache-Control:Private 內(nèi)容只緩存到私有緩存中

Cache-Control:no-cache 所有內(nèi)容都不會被緩存

Cache-Control:no-store 用于防止重要的信息被無意的發(fā)布。在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存。

Cache-Control:max-age 指示客戶機可以接收生存期不大于指定時間(以秒為單位)的響應(yīng)。

Cache-Control:min-fresh 指示客戶機可以接收響應(yīng)時間小于當(dāng)前時間加上指定時間的響應(yīng)。

Cache-Control:max-stale 指示客戶機可以接收超出超時期間的響應(yīng)消息。如果指定max-stale消息的值,那么客戶機可以接收超出超時期指定值之內(nèi)的響應(yīng)消息。

Accept:瀏覽器端可以接受的MIME類型。例如:Accept: text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html 也就是我們常說的html文檔,如果服務(wù)器無法返回text/html類型的數(shù)據(jù),服務(wù)器應(yīng)該返回一個406錯誤(non acceptable)。通配符 * 代表任意類型,例如 Accept: */* 代表瀏覽器可以處理所有類型,(一般瀏覽器發(fā)給服務(wù)器都是發(fā)這個)。

Accept-Encoding:瀏覽器申明自己可接收的編碼方法,通常指定壓縮方法,是否支持壓縮,支持什么壓縮方法(gzip,deflate);Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。例如: Accept-Encoding: gzip, deflate。如果請求消息中沒有設(shè)置這個域,服務(wù)器假定客戶端對各種內(nèi)容編碼都可以接受。

Accept-Language:瀏覽器申明自己接收的語言。語言跟字符集的區(qū)別:中文是語言,中文有多種字符集,比如big5,gb2312,gbk等等;例如:Accept-Language: en-us。如果請求消息中沒有設(shè)置這個報頭域,服務(wù)器假定客戶端對各種語言都可以接受。

Accept-Charset:瀏覽器可接受的字符集。如果在請求消息中沒有設(shè)置這個域,缺省表示任何字符集都可以接受。

User-Agent:告訴HTTP服務(wù)器,客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本。

例如: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)。

Content-Type:例如:Content-Type: application/x-www-form-urlencoded。

Referer:包含一個URL,用戶從該URL代表的頁面出發(fā)訪問當(dāng)前請求的頁面。提供了Request的上下文信息的服務(wù)器,告訴服務(wù)器我是從哪個鏈接過來的,比如從我主頁上鏈接到一個朋友那里,他的服務(wù)器就能夠從HTTP Referer中統(tǒng)計出每天有多少用戶點擊我主頁上的鏈接訪問他的網(wǎng)站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Connection

例如:Connection: keep-alive 當(dāng)一個網(wǎng)頁打開完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉,如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁,會繼續(xù)使用這一條已經(jīng)建立的連接。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)容之前計算它的大小。

Connection: close 代表一個Request完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉,當(dāng)客戶端再次發(fā)送Request,需要重新建立TCP連接。

Host:(發(fā)送請求時,該頭域是必需的)主要用于指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的。HTTP/1.1請求必須包含主機頭域,否則系統(tǒng)會以400狀態(tài)碼返回。

例如: 我們在瀏覽器中輸入:http://www.guet.edu.cn/index.html,瀏覽器發(fā)送的請求消息中,就會包含Host請求頭域:Host:http://www.guet.edu.cn,此處使用缺省端口號80,若指定了端口號,則變成:Host:指定端口號。

Cookie:最重要的請求頭之一, 將cookie的值發(fā)送給HTTP服務(wù)器。

Content-Length:表示請求消息正文的長度。例如:Content-Length: 38。

Authorization:授權(quán)信息,通常出現(xiàn)在對服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中。主要用于證明客戶端有權(quán)查看某個資源。當(dāng)瀏覽器訪問一個頁面時,如果收到服務(wù)器的響應(yīng)代碼為401(未授權(quán)),可以發(fā)送一個包含Authorization請求報頭域的請求,要求服務(wù)器對其進(jìn)行驗證。

UA-Pixels,UA-Color,UA-OS,UA-CPU:由某些版本的IE瀏覽器所發(fā)送的非標(biāo)準(zhǔn)的請求頭,表示屏幕大小、顏色深度、操作系統(tǒng)和CPU類型。

From:請求發(fā)送者的email地址,由一些特殊的Web客戶程序使用,瀏覽器不會用到它。

Range:可以請求實體的一個或者多個子范圍。例如,

表示頭500個字節(jié):bytes=0-499

表示第二個500字節(jié):bytes=500-999

表示最后500個字節(jié):bytes=-500

表示500字節(jié)以后的范圍:bytes=500-

第一個和最后一個字節(jié):bytes=0-0,-1

同時指定幾個范圍:bytes=500-600,601-999

但是服務(wù)器可以忽略此請求頭,如果無條件GET包含Range請求頭,響應(yīng)會以狀態(tài)碼206(PartialContent)返回而不是以200(OK)。

6、HTTP常見的響應(yīng)頭

Allow:服務(wù)器支持哪些請求方法(如GET、POST等)。

Date:表示消息發(fā)送的時間,時間的描述格式由rfc822定義。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標(biāo)準(zhǔn)時,換算成本地時間,需要知道用戶所在的時區(qū)。你可以用setDateHeader來設(shè)置這個頭以避免轉(zhuǎn)換時間格式的麻煩

Expires:指明應(yīng)該在什么時候認(rèn)為文檔已經(jīng)過期,從而不再緩存它,重新從服務(wù)器獲取,會更新緩存。過期之前使用本地緩存。HTTP1.1的客戶端和緩存會將非法的日期格式(包括0)看作已經(jīng)過期。eg:為了讓瀏覽器不要緩存頁面,我們也可以將Expires實體報頭域,設(shè)置為0。

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

P3P:用于跨域設(shè)置Cookie, 這樣可以解決iframe跨域訪問cookie的問題

例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie:非常重要的header, 用于把cookie發(fā)送到客戶端瀏覽器,每一個寫入cookie都會生成一個Set-Cookie。

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

ETag:和If-None-Match 配合使用。

Last-Modified:用于指示資源的最后修改日期和時間。Last-Modified也可用setDateHeader方法來設(shè)置。

Content-Type:WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型和字符集。Servlet默認(rèn)為text/plain,但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置Content-Type,因此HttpServletResponse提供了一個專用的方法setContentType。可在web.xml文件中配置擴展名和MIME類型的對應(yīng)關(guān)系。

例如:Content-Type: text/html;charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

媒體類型的格式為:大類/小類,比如text/html。

IANA(The Internet Assigned Numbers Authority,互聯(lián)網(wǎng)數(shù)字分配機構(gòu))定義了8個大類的媒體類型,分別是:

application— (比如: application/vnd.ms-excel.)

audio (比如: audio/mpeg.)

image (比如: image/png.)

message (比如,:message/http.)

model(比如:model/vrml.)

multipart (比如:multipart/form-data.)

text(比如:text/html.)

video(比如:video/quicktime.)

Content-Range:用于指定整個實體中的一部分的插入位置,他也指示了整個實體的長度。在服務(wù)器向客戶返回一個部分響應(yīng),它必須描述響應(yīng)覆蓋的范圍和整個實體長度。一般格式:Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。

例如,傳送頭500個字節(jié)次字段的形式:Content-Range:bytes0-499/1234如果一個http消息包含此節(jié)(例如,對范圍請求的響 應(yīng)或?qū)σ幌盗蟹秶闹丿B請求),Content-Range表示傳送的范圍。

Content-Length:指明實體正文的長度,以字節(jié)方式存儲的十進(jìn)制數(shù)字來表示。在數(shù)據(jù)下行的過程中,Content-Length的方式要預(yù)先在服務(wù)器中緩存所有數(shù)據(jù),然后所有數(shù)據(jù)再一股腦兒地發(fā)給客戶端。只有當(dāng)瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢,可以把輸出文檔寫入ByteArrayOutputStram,完成后查看其大小,然后把該值放入Content-Length頭,最后通過byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。

例如: Content-Length: 19847

Content-Encoding:WEB服務(wù)器表明自己使用了什么壓縮方法(gzip,deflate)壓縮響應(yīng)中的對象。只有在解碼之后才可以得到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頁面,為其他瀏覽器返回普通頁面。

例如:Content-Encoding:gzip

Content-Language:WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對象所用的自然語言。例如: Content-Language:da。沒有設(shè)置該域則認(rèn)為實體內(nèi)容將提供給所有的語言閱讀。

Server:指明HTTP服務(wù)器用來處理請求的軟件信息。例如:Server: Microsoft-IIS/7.5、Server:Apache-Coyote/1.1。此域能包含多個產(chǎn)品標(biāo)識和注釋,產(chǎn)品標(biāo)識一般按照重要性排序。

X-AspNet-Version:如果網(wǎng)站是用ASP.NET開發(fā)的,這個header用來表示ASP.NET的版本。

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:表示網(wǎng)站是用什么技術(shù)開發(fā)的。

例如: X-Powered-By: ASP.NET

Connection:

例如:Connection: keep-alive 當(dāng)一個網(wǎng)頁打開完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉,如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁,會繼續(xù)使用這一條已經(jīng)建立的連接。

Connection: close 代表一個Request完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉,當(dāng)客戶端再次發(fā)送Request,需要重新建立TCP連接。

Location:用于重定向一個新的位置,包含新的URL地址。表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的,而是通過HttpServletResponse的sendRedirect方法,該方法同時設(shè)置狀態(tài)代碼為302。Location響應(yīng)報頭域常用在更換域名的時候。

Refresh:表示瀏覽器應(yīng)該在多少時間之后刷新文檔,以秒計。除了刷新當(dāng)前文檔之外,你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設(shè)置HTML頁面HEAD區(qū)的實現(xiàn),這是因為,自動刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫者十分重要。但是,對于Servlet來說,直接設(shè)置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”,而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此,連續(xù)刷新要求每次都發(fā)送一個Refresh頭,而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新,不管是使用Refresh頭還是。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分,而是一個擴展,但Netscape和IE都支持它。

WWW-Authenticate:該響應(yīng)報頭域必須被包含在401(未授權(quán)的)響應(yīng)消息中,客戶端收到401響應(yīng)消息時候,并發(fā)送Authorization報頭域請求服務(wù)器對其進(jìn)行驗證時,服務(wù)端響應(yīng)報頭就包含該報頭域。

eg:WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服務(wù)器對請求資源采用的是基本驗證機制。

緩存的實現(xiàn)原理

WEB緩存(cache)位于Web服務(wù)器和客戶端之間。

緩存會根據(jù)請求保存輸出內(nèi)容的副本,例如html頁面,圖片,文件,當(dāng)下一個請求來到的時候:如果是相同的URL,緩存直接使用副本響應(yīng)訪問請求,而不是向源服務(wù)器再次發(fā)送請求。

HTTP協(xié)議定義了相關(guān)的消息頭來使WEB緩存盡可能好的工作。

1、緩存的優(yōu)點

減少相應(yīng)延遲:因為請求從緩存服務(wù)器(離客戶端更近)而不是源服務(wù)器被相應(yīng),這個過程耗時更少,讓web服務(wù)器看上去相應(yīng)更快。

減少網(wǎng)絡(luò)帶寬消耗:當(dāng)副本被重用時會減低客戶端的帶寬消耗;客戶可以節(jié)省帶寬費用,控制帶寬的需求的增長并更易于管理。

2、客戶端緩存生效的常見流程

服務(wù)器收到請求時,會在200OK中回送該資源的Last-Modified和ETag頭,客戶端將該資源保存在cache中,并記錄這兩個屬性。當(dāng)客戶端需要發(fā)送相同的請求時,會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應(yīng)中Last-Modified和ETag頭的值。服務(wù)器通過這兩個頭判斷本地資源未發(fā)生變化,客戶端不需要重新下載,返回304響應(yīng)。

3、Web緩存機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請求,同時在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量;HTTP利用一個“過期(expiration)”機制來為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬;HTTP用“驗證(validation)”機制來為此目的。

HTTP定義了3種緩存機制:

1)Freshness:允許一個回應(yīng)消息可以在源服務(wù)器不被重新檢查,并且可以由服務(wù)器和客戶端來控制。例如,Expires回應(yīng)頭給了一個文檔不可用的時間。Cache-Control中的max-age標(biāo)識指明了緩存的最長時間;

2)Validation:用來檢查以一個緩存的回應(yīng)是否仍然可用。例如,如果一個回應(yīng)有一個Last-Modified回應(yīng)頭,緩存能夠使用If-Modified-Since來判斷是否已改變,以便判斷根據(jù)情況發(fā)送請求;

3)Invalidation:在另一個請求通過緩存的時候,常常有一個副作用。例如,如果一個URL關(guān)聯(lián)到一個緩存回應(yīng),但是其后跟著POST、PUT和DELETE的請求的話,緩存就會過期。

HTTP應(yīng)用

1、斷點續(xù)傳的實現(xiàn)原理

HTTP協(xié)議的GET方法,支持只請求某個資源的某一部分;

206 Partial Content 部分內(nèi)容響應(yīng);

Range 請求的資源范圍;

Content-Range 響應(yīng)的資源范圍;

在連接斷開重連時,客戶端只請求該資源未下載的部分,而不是重新請求整個資源,來實現(xiàn)斷點續(xù)傳。

分塊請求資源實例:

Eg1:Range: bytes=306302- :請求這個資源從306302個字節(jié)到末尾的部分;

Eg2:Content-Range: bytes 306302-604047/604048:響應(yīng)中指示攜帶的是該資源的第306302-604047的字節(jié),該資源共604048個字節(jié);

客戶端通過并發(fā)的請求相同資源的不同片段,來實現(xiàn)對某個資源的并發(fā)分塊下載。從而達(dá)到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。

2、多線程下載的原理

下載工具開啟多個發(fā)出HTTP請求的線程;

每個http請求只請求資源文件的一部分:Content-Range: bytes 20000-40000/47000;

合并每個線程下載的文件。

3、http代理

http代理服務(wù)器

代理服務(wù)器英文全稱是Proxy Server,其功能就是代理網(wǎng)絡(luò)用戶去取得網(wǎng)絡(luò)信息。形象的說:它是網(wǎng)絡(luò)信息的中轉(zhuǎn)站。

代理服務(wù)器是介于瀏覽器和Web服務(wù)器之間的一臺服務(wù)器,有了它之后,瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁而是向代理服務(wù)器發(fā)出請求,Request信號會先送到代理服務(wù)器,由代理服務(wù)器來取回瀏覽器所需要的信息并傳送給你的瀏覽器。

而且,大部分代理服務(wù)器都具有緩沖的功能,就好象一個大的Cache,它有很大的存儲空間,它不斷將新取得數(shù)據(jù)儲存到它本機的存儲器上,如果瀏覽器所請求的數(shù)據(jù)在它本機的存儲器上已經(jīng)存在而且是最新的,那么它就不重新從Web服務(wù)器取數(shù)據(jù),而直接將存儲器上的數(shù)據(jù)傳送給用戶的瀏覽器,這樣就能顯著提高瀏覽速度和效率。更重要的是:Proxy Server(代理服務(wù)器)是Internet鏈路級網(wǎng)關(guān)所提供的一種重要的安全功能,它的工作主要在開放系統(tǒng)互聯(lián)(OSI)模型的對話層。

http代理服務(wù)器的主要功能:

1)突破自身IP訪問限制,訪問國外站點。如:教育網(wǎng)、169網(wǎng)等網(wǎng)絡(luò)用戶可以通過代理訪問國外網(wǎng)站;

2)訪問一些單位或團體內(nèi)部資源,如某大學(xué)FTP(前提是該代理地址在該資源的允許訪問范圍之內(nèi)),使用教育網(wǎng)內(nèi)地址段免費代理服務(wù)器,就可以用于對教育 網(wǎng)開放的各類FTP下載上傳,以及各類資料查詢共享等服務(wù);

3)突破中國電信的IP封鎖:中國電信用戶有很多網(wǎng)站是被限制訪問的,這種限制是人為的,不同Serve對地址的封鎖是不同的。所以不能訪問時可以換一個國外的代理服務(wù)器試試;

4)提高訪問速度:通常代理服務(wù)器都設(shè)置一個較大的硬盤緩沖區(qū),當(dāng)有外界的信息通過時,同時也將其保存到緩沖區(qū)中,當(dāng)其他用戶再訪問相同的信息時,則直接由緩沖區(qū)中取出信息,傳給用戶,以提高訪問速度;

5)隱藏真實IP:上網(wǎng)者也可以通過這種方法隱藏自己的IP,免受攻擊。

對于客戶端瀏覽器而言,http代理服務(wù)器相當(dāng)于服務(wù)器。

而對于Web服務(wù)器而言,http代理服務(wù)器又擔(dān)當(dāng)了客戶端的角色。

4、虛擬主機

虛擬主機:是在網(wǎng)絡(luò)服務(wù)器上劃分出一定的磁盤空間供用戶放置站點、應(yīng)用組件等,提供必要的站點功能與數(shù)據(jù)存放、傳輸功能。

所謂虛擬主機,也叫“網(wǎng)站空間”就是把一臺運行在互聯(lián)網(wǎng)上的服務(wù)器劃分成多個“虛擬”的服務(wù)器,每一個虛擬主機都具有獨立的域名和完整的Internet服務(wù)器(支持WWW、FTP、E-mail等)功能。一臺服務(wù)器上的不同虛擬主機是各自獨立的,并由用戶自行管理。但一臺服務(wù)器主機只能夠支持一定數(shù)量的虛擬主機,當(dāng)超過這個數(shù)量時,用戶將會感到性能急劇下降。

虛擬主機的實現(xiàn)原理

虛擬主機是用同一個WEB服務(wù)器,為不同域名網(wǎng)站提供服務(wù)的技術(shù)。Apache、Tomcat等均可通過配置實現(xiàn)這個功能。

相關(guān)的HTTP消息頭:Host。

例如:Host: www.baidu.com

客戶端發(fā)送HTTP請求的時候,會攜帶Host頭,Host頭記錄的是客戶端輸入的域名。這樣服務(wù)器可以根據(jù)Host頭確認(rèn)客戶要訪問的是哪一個域名。

HTTPS傳輸協(xié)議原理

HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標(biāo)的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎(chǔ)是SSL,因此加密的詳細(xì)內(nèi)容請看SSL。

1、兩種基本的加解密算法類型

對稱加密:密鑰只有一個,加密解密為同一個密碼,且加解密速度快,典型的對稱加密算法有DES、AES等。

非對稱加密:密鑰成對出現(xiàn)(且根據(jù)公鑰無法推知私鑰,根據(jù)私鑰也無法推知公鑰),加密解密使用不同密鑰(公鑰加密需要私鑰解密,私鑰加密需要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密算法有RSA、DSA等。

2、HTTPS通信過程

3、HTTPS通信的優(yōu)點

客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到;

加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文;

客戶端到服務(wù)端的通信是安全的。

HTTP認(rèn)證方式

HTTP請求報頭: Authorization

HTTP響應(yīng)報頭: WWW-Authenticate

HTTP認(rèn)證是基于質(zhì)詢/回應(yīng)(challenge/response)的認(rèn)證模式。

1 基本認(rèn)證 basic authentication(HTTP1.0提出的認(rèn)證方法)

基本認(rèn)證是一種用來允許Web瀏覽器或其他客戶端程序在請求時提供用戶名和口令形式的身份憑證的一種登錄驗證方式。

把 "用戶名+冒號+密碼"用BASE64算法加密后的字符串放在http request 中的header Authorization中發(fā)送給服務(wù)端。

客戶端對于每一個realm,通過提供用戶名和密碼來進(jìn)行認(rèn)證的方式。

包含密碼的明文傳遞。

當(dāng)瀏覽器訪問使用基本認(rèn)證的網(wǎng)站的時候, 瀏覽器會提示你輸入用戶名和密碼,如下圖:

假如用戶名密碼錯誤的話,服務(wù)器會返回401,如下圖:

基本認(rèn)證步驟:

1、客戶端訪問一個受http基本認(rèn)證保護(hù)的資源。

2、服務(wù)器返回401狀態(tài),要求客戶端提供用戶名和密碼進(jìn)行認(rèn)證。(驗證失敗的時候,響應(yīng)頭會加上WWW-Authenticate: Basic realm="請求域"。)

401 Unauthorized

WWW-Authenticate: Basic realm="WallyWorld"

3、客戶端將輸入的用戶名密碼用Base64進(jìn)行編碼后,采用非加密的明文方式傳送給服務(wù)器。

Authorization: Basic xxxxxxxxxx.

4、服務(wù)器將Authorization頭中的用戶名密碼解碼并取出,進(jìn)行驗證,如果認(rèn)證成功,則返回相應(yīng)的資源。如果認(rèn)證失敗,則仍返回401狀態(tài),要求重新進(jìn)行認(rèn)證。

特記事項:

1、Http是無狀態(tài)的,同一個客戶端對同一個realm內(nèi)資源的每一個訪問會被要求進(jìn)行認(rèn)證。

2、客戶端通常會緩存用戶名和密碼,并和authentication realm一起保存,所以,一般不需要你重新輸入用戶名和密碼。

3、以非加密的明文方式傳輸,雖然轉(zhuǎn)換成了不易被人直接識別的字符串,但是無法防止用戶名密碼被惡意盜用。雖然用肉眼看不出來,但用程序很容易解密。

優(yōu)點:

基本認(rèn)證的一個優(yōu)點是基本上所有流行的網(wǎng)頁瀏覽器都支持基本認(rèn)證。基本認(rèn)證很少在可公開訪問的互聯(lián)網(wǎng)網(wǎng)站上使用,有時候會在小的私有系統(tǒng)中使用(如路由器網(wǎng)頁管理接口)。后來的機制HTTP摘要認(rèn)證是為替代基本認(rèn)證而開發(fā)的,允許密鑰以相對安全的方式在不安全的通道上傳輸。

程序員和系統(tǒng)管理員有時會在可信網(wǎng)絡(luò)環(huán)境中使用基本認(rèn)證,使用Telnet或其他明文網(wǎng)絡(luò)協(xié)議工具手動地測試Web服務(wù)器。這是一個麻煩的過程,但是網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容是人可讀的,以便進(jìn)行診斷。

缺點:

雖然基本認(rèn)證非常容易實現(xiàn),但該方案建立在以下的假設(shè)的基礎(chǔ)上,即:客戶端和服務(wù)器主機之間的連接是安全可信的。特別是,如果沒有使用SSL/TLS這樣的傳輸層安全的協(xié)議,那么以明文傳輸?shù)拿荑€和口令很容易被攔截。該方案也同樣沒有對服務(wù)器返回的信息提供保護(hù)。

現(xiàn)存的瀏覽器保存認(rèn)證信息直到標(biāo)簽頁或瀏覽器被關(guān)閉,或者用戶清除歷史記錄。HTTP沒有為服務(wù)器提供一種方法指示客戶端丟棄這些被緩存的密鑰。這意味著服務(wù)器端在用戶不關(guān)閉瀏覽器的情況下,并沒有一種有效的方法來讓用戶登出。

一個例子:

?這一個典型的HTTP客戶端和HTTP服務(wù)器的對話,服務(wù)器安裝在同一臺計算機上(localhost),包含以下步驟:

客戶端請求一個需要身份認(rèn)證的頁面,但是沒有提供用戶名和口令。這通常是用戶在地址欄輸入一個URL,或是打開了一個指向該頁面的鏈接。服務(wù)端響應(yīng)一個401應(yīng) 答碼,并提供一個認(rèn)證域。接到應(yīng)答后,客戶端顯示該認(rèn)證域(通常是所訪問的計算機或系統(tǒng)的描述)給用戶并提示輸入用戶名和口令。此時用戶可以選擇確定或取消。用戶輸入了用戶名和口令后,客戶端軟件會在原先的請求上增加認(rèn)證消息頭(值是base64encode(username+":"+password)),然后重新發(fā)送再次嘗試。在本例中,服務(wù)器接受了該認(rèn)證屏幕并返回了頁面。如果用戶憑據(jù)非法或無效,服務(wù)器可能再次返回401應(yīng)答碼,客戶端可以再次提示用戶輸入口令。注意:客戶端有可能不需要用戶交互,在第一次請求中就發(fā)送認(rèn)證消息頭。

客戶端請求(沒有認(rèn)證信息):

GET /private/index.html HTTP/1.0

Host: localhost

(跟隨一個換行,以回車(CR)加換行(LF)的形式)

服務(wù)端應(yīng)答:

HTTP/1.0 401 Authorization Required

Server: HTTPd/1.0

Date: Sat, 27 Nov 2004 10:18:15 GMT

WWW-Authenticate: Basic realm="Secure Area"

Content-Type: text/html

Content-Length: 311

客戶端的請求(用戶名“"Aladdin”,口令, password “open sesame”):

GET /private/index.html HTTP/1.0

Host: localhostAuthorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

(跟隨一個空行,如上所述)

服務(wù)端的應(yīng)答:

HTTP/1.0 200 OK

Server: HTTPd/1.0

Date: Sat, 27 Nov 2004 10:19:07 GMT

Content-Type: text/html

Content-Length: 10476

(跟隨一個空行,隨后是需憑據(jù)頁的HTML文本)。

HTTP OAuth認(rèn)證OAuth對于Http來說,就是放在Authorization header中的不是用戶名密碼, 而是一個token。微軟的Skydrive就是使用這樣的方式。

2、摘要認(rèn)證 digest authentication(HTTP1.1提出的基本認(rèn)證的替代方法)

這個認(rèn)證可以看做是基本認(rèn)證的增強版本,不包含密碼的明文傳遞。

引入了一系列安全增強的選項;“保護(hù)質(zhì)量”(qop)、隨機數(shù)計數(shù)器由客戶端增加、以及客戶生成的隨機數(shù)。

在HTTP摘要認(rèn)證中使用 MD5 加密是為了達(dá)成"不可逆的",也就是說,當(dāng)輸出已知的時候,確定原始的輸入應(yīng)該是相當(dāng)困難的。如果密碼本身太過簡單,也許可以

通過嘗試所有可能的輸入來找到對應(yīng)的輸出(窮舉攻擊),甚至可以通過字典或者適當(dāng)?shù)牟檎冶砑涌觳檎宜俣取?/p>

示例及說明

下面的例子僅僅涵蓋了“auth”保護(hù)質(zhì)量的代碼,因為在撰寫期間,所知道的只有Opera和Konqueror網(wǎng)頁瀏覽器支持“auth-int”(帶完整性保護(hù)的認(rèn)證)。

典型的認(rèn)證過程包括如下步驟:

客戶端請求一個需要認(rèn)證的頁面,但是不提供用戶名和密碼。通常這是由于用戶簡單的輸入了一個地址或者在頁面中點擊了某個超鏈接。

服務(wù)器返回401 "Unauthorized" 響應(yīng)代碼,并提供認(rèn)證域(realm),以及一個隨機生成的、只使用一次的數(shù)值,稱為密碼隨機數(shù) nonce。

此時,瀏覽器會向用戶提示認(rèn)證域(realm)(通常是所訪問的計算機或系統(tǒng)的描述),并且提示用戶名和密碼。用戶此時可以選擇取消。

一旦提供了用戶名和密碼,客戶端會重新發(fā)送同樣的請求,但是添加了一個認(rèn)證頭包括了響應(yīng)代碼。

注意:客戶端可能已經(jīng)擁有了用戶名和密碼,因此不需要提示用戶,比如以前存儲在瀏覽器里的。

客戶端請求 (無認(rèn)證):

GET /dir/index.html HTTP/1.0

Host: localhost

(跟隨一個新行,形式為一個回車再跟一個換行)

服務(wù)器響應(yīng):

HTTP/1.0 401 Unauthorized

Server: HTTPd/0.9

Date: Sun, 10 Apr 2005 20:26:47 GMT

WWW-Authenticate: Digest realm="testrealm@host.com",? //認(rèn)證域

qop="auth,auth-int",? //保護(hù)質(zhì)量

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",? //服務(wù)器密碼隨機數(shù)

opaque="5ccc069c403ebaf9f0171e9517f40e41"

Content-Type: text/html

Content-Length: 311

客戶端請求 (用戶名 "Mufasa", 密碼 "Circle Of Life"):

GET /dir/index.html HTTP/1.0

Host: localhost

Authorization: Digest username="Mufasa",

realm="testrealm@host.com",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

uri="/dir/index.html",

qop=auth,

nc=00000001,? ? //請求計數(shù)

cnonce="0a4f113b",? //客戶端密碼隨機數(shù)

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

(跟隨一個新行,形式如前所述)。

服務(wù)器響應(yīng):

HTTP/1.0 200 OK

Server: HTTPd/0.9

Date: Sun, 10 Apr 2005 20:27:03 GMT

Content-Type: text/html

Content-Length: 7984

(隨后是一個空行,然后是所請求受限制的HTML頁面)

response 值由三步計算而成。當(dāng)多個數(shù)值合并的時候,使用冒號作為分割符:

1、對用戶名、認(rèn)證域(realm)以及密碼的合并值計算 MD5 哈希值,結(jié)果稱為 HA1。

2、對HTTP方法以及URI的摘要的合并值計算 MD5 哈希值,例如,"GET" 和 "/dir/index.html",結(jié)果稱為 HA2。

3、對HA1、服務(wù)器密碼隨機數(shù)(nonce)、請求計數(shù)(nc)、客戶端密碼隨機數(shù)(cnonce)、保護(hù)質(zhì)量(qop)以及 HA2 的合并值計算 MD5 哈希值。結(jié)果即為客戶端提供的response 值。

因為服務(wù)器擁有與客戶端同樣的信息,因此服務(wù)器可以進(jìn)行同樣的計算,以驗證客戶端提交的 response 值的正確性。在上面給出的例子中,結(jié)果是如下計算的。

(MD5()表示用于計算MD5哈希值的函數(shù);“\”表示接下一行;引號并不參與計算)

HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )

= 939e7578ed9e3c518a452acee763bce9

HA2 = MD5( "GET:/dir/index.html" )

= 39aff3a2bab6126f332b942af96d3366

Response = MD5( "939e7578ed9e3c518a452acee763bce9:\

dcd98b7102dd2f0e8b11d0f600bfb0c093:\

00000001:0a4f113b:auth:\

39aff3a2bab6126f332b942af96d3366" )

= 6629fae49393a05397450978507c4ef1

此時客戶端可以提交一個新的請求,重復(fù)使用服務(wù)器密碼隨機數(shù)(nonce)(服務(wù)器僅在每次“401”響應(yīng)后發(fā)行新的nonce),但是提供新的客戶端密碼隨機數(shù)(cnonce)。在后續(xù)的請求中,十六進(jìn)制請求計數(shù)器(nc)必須比前一次使用的時候要大,否則攻擊者可以簡單的使用同樣的認(rèn)證信息重放老的請求。由服務(wù)器來確保在每個發(fā)出的密碼隨機數(shù)nonce時,計數(shù)器是在增加的,并拒絕掉任何錯誤的請求。顯然,改變HTTP方法和/或計數(shù)器數(shù)值都會導(dǎo)致不同的 response值。

服務(wù)器應(yīng)當(dāng)記住最近所生成的服務(wù)器密碼隨機數(shù)nonce的值。也可以在發(fā)行每一個密碼隨機數(shù)nonce后,記住過一段時間讓它們過期。如果客戶端使用了一個過期的值,服務(wù)器應(yīng)該響應(yīng)“401”狀態(tài)號,并且在認(rèn)證頭中添加stale=TRUE,表明客戶端應(yīng)當(dāng)使用新提供的服務(wù)器密碼隨機數(shù)nonce重發(fā)請求,而不必提示用戶其它用戶名和口令。

服務(wù)器不需要保存任何過期的密碼隨機數(shù),它可以簡單的認(rèn)為所有不認(rèn)識的數(shù)值都是過期的。服務(wù)器也可以只允許每一個服務(wù)器密碼隨機數(shù)nonce使用一次,當(dāng)然,這樣就會迫使客戶端在發(fā)送每個請求的時候重復(fù)認(rèn)證過程。需要注意的是,在生成后立刻過期服務(wù)器密碼隨機數(shù)nonce是不行的,因為客戶端將沒有任何機會來使用這個nonce。

http的狀態(tài)響應(yīng)碼

1**(信息類):表示接收到請求并且繼續(xù)處理

100——客戶必須繼續(xù)發(fā)出請求

101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本

2**(響應(yīng)成功):表示動作被成功接收、理解和接受

200——表明該請求被成功地完成,所請求的資源發(fā)送回客戶端

201——提示知道新文件的URL

202——接受和處理、但處理未完成

203——返回信息不確定或不完整

204——請求收到,但返回信息為空

205——服務(wù)器完成了請求,用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過的文件

206——服務(wù)器已經(jīng)完成了部分用戶的GET請求

3**(重定向類):為了完成指定的動作,必須接受進(jìn)一步處理

300——請求的資源可在多處得到

301——本網(wǎng)頁被永久性轉(zhuǎn)移到另一個URL

302——請求的網(wǎng)頁被轉(zhuǎn)移到一個新的地址,但客戶訪問仍繼續(xù)通過原始URL地址,重定向,新的URL會在response中的Location中返回,瀏覽器將會使用新的URL發(fā)出新的Request。

303——建議客戶訪問其他URL或訪問方式

304——自從上次請求后,請求的網(wǎng)頁未修改過,服務(wù)器返回此響應(yīng)時,不會返回網(wǎng)頁內(nèi)容,代表上次的文檔已經(jīng)被緩存了,還可以繼續(xù)使用

305——請求的資源必須從服務(wù)器指定的地址得到

306——前一版本HTTP中使用的代碼,現(xiàn)行版本中不再使用

307——申明請求的資源臨時性刪除

4**(客戶端錯誤類):請求包含錯誤語法或不能正確執(zhí)行

400——客戶端請求有語法錯誤,不能被服務(wù)器所理解

401——請求未經(jīng)授權(quán),這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用

HTTP 401.1 - 未授權(quán):登錄失敗

HTTP 401.2 - 未授權(quán):服務(wù)器配置問題導(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——禁止訪問,服務(wù)器收到請求,但是拒絕提供服務(wù)

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——一個404錯誤表明可連接服務(wù)器,但服務(wù)器無法取得所請求的網(wǎng)頁,請求資源不存在。eg:輸入了錯誤的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ù)器不能滿足請求長。

5**(服務(wù)端錯誤類):服務(wù)器不能正確執(zhí)行一個正確的請求

HTTP 500 - 服務(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)錯誤

HTTP 503:由于超載或停機維護(hù),服務(wù)器目前無法使用,一段時間后可能恢復(fù)正常

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,797評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,179評論 3 414
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,628評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,642評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 71,444評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,948評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,040評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,185評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,717評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,794評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,418評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,414評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 47,750評論 2 370

推薦閱讀更多精彩內(nèi)容