3協(xié)議參數(shù)
3．1HTTP版本
HTTP使用一個(gè)“<major>.<minor>”模式來(lái)標(biāo)志協(xié)議版本。協(xié)議版本就是要允許發(fā)送者表達(dá)message格式的信息以及它理解更多HTTP協(xié)議的能力（不只是說(shuō)通訊的功能）。加了不影響通訊行為的MESSAGE組件或加了擴(kuò)展的域值都不必改變版本號(hào)。<minor>增大表示協(xié)議被改變，一般的MESSAGE解析算法沒(méi)有變，但是增加了MESSAGE語(yǔ)義也就增加了發(fā)送者額外的功能。<major>增大如果MESSAGE的格式改變了。
HTTPmessage的HTTP版本在MESSAGE的頭一行的版本域中被表示。
HTTP-Version =”HTTP””/”1*digit”.”1*DIGIT
注意major和minor數(shù)每一個(gè)都可以獨(dú)立對(duì)待。因此HTTP/2。4比HTTP/2。13低，而HTTP/2。4又比HTTP/12。3低。前面的0必須被接收者忽略而發(fā)送者千萬(wàn)不要發(fā)。
一個(gè)發(fā)送包含“HTTP/1。1”版本的request或response信息必須最少與這個(gè)規(guī)范條件兼容。而一個(gè)和這個(gè)規(guī)范最少條件兼容的應(yīng)用應(yīng)該在他們的MESSAGE中標(biāo)明HTTP/1。1版本，并且對(duì)于于HTTP/1。0不兼容的MESSAGE必須標(biāo)明HTTP/1。1版本。關(guān)于什么時(shí)候送規(guī)范的HTTPV值更多細(xì)節(jié)看RFC2145[36]。
應(yīng)用的HTTP版本是應(yīng)用最少條件兼容的最高HTTP版本。
Proxy和gateway應(yīng)用需要仔細(xì)對(duì)待轉(zhuǎn)發(fā)不同于自身應(yīng)用版本的message。因?yàn)檫^(guò)來(lái)的MESSAGE中的HTTP版本代表了發(fā)送者的協(xié)議能力，一個(gè)PROXY/GATEWAY千萬(wàn)不要發(fā)送一個(gè)高于該版本的MESSAGE。相反，如果接受了一個(gè)更高版本也不要減低或報(bào)錯(cuò)或轉(zhuǎn)向TUNNEL行為。
RFC2068[33]發(fā)布時(shí)發(fā)現(xiàn)了與HTTP/1。0proxy交互時(shí)出現(xiàn)的問(wèn)題，緩存proxy必須，gateway可以，tunnel千萬(wàn)不要升級(jí)request到他們支持的最高版本。Proxy和gateway的Response必須和那個(gè)request保持同一個(gè)版本。
注意：在HTTP版本間的轉(zhuǎn)換可能包含頭區(qū)某域的改變，而這些改變可能被要求或被拒絕。
3．2統(tǒng)一資源定位符
關(guān)于URI以前出現(xiàn)的名稱(chēng)有：WWW地址，通用文檔標(biāo)志，通用資源標(biāo)志，最后，代表URL和URN的組合。只要和HTTP相關(guān)，URI就是一個(gè)簡(jiǎn)單的格式化字符串，通過(guò)名稱(chēng)，地址或其他特征來(lái)標(biāo)志一個(gè)資源。
3．2．1普通語(yǔ)法
在HTTP中URI可以以一個(gè)絕對(duì)的形式表現(xiàn)或相對(duì)于一些知道的基本的URI，這取決于使用的上下文。這兩種形式被區(qū)分于：絕對(duì)的URI總是以一個(gè)模式名稱(chēng)跟一個(gè)冒號(hào)開(kāi)始。關(guān)于URL的詞法和語(yǔ)法的絕對(duì)定義信息，需要看“Uniform Resource Identifiers (URI): Generic Syntax and Semantics,” RFC 2396 [42]（取代了RFCs1738[4]和RFC1808[11]）；而其中的部分定義“URI-reference”, “absoluteURI”, “relativeURI”,“port”, “host”,“abs_path”, “rel_path”, 和 “authority”在本規(guī)范中也被使用。
HTTP協(xié)議并沒(méi)有對(duì)URI的長(zhǎng)度有一個(gè)預(yù)先的限制。服務(wù)器必須能夠處理任何他們提供資源的響應(yīng)URI，而且應(yīng)該能夠處理無(wú)限長(zhǎng)度的URI，如果他們提供基于GET的表達(dá)形式。一個(gè)服務(wù)器應(yīng)該返回414如果一個(gè)URI比服務(wù)器能處理的URI還長(zhǎng)的話。
注意：服務(wù)器應(yīng)該小心對(duì)待長(zhǎng)度超過(guò)255個(gè)字節(jié)的URI，因?yàn)橐恍├?/SPAN>client和proxy實(shí)現(xiàn)可能不支持這些長(zhǎng)度。
3．2．2http URL
“http”模式被用來(lái)通過(guò)HTTP協(xié)議定位網(wǎng)絡(luò)資源。下面為httpURL定義了模式化的詞法和語(yǔ)法.
http_URL = "http:" "http://" host [ ":" port ] [ abs_path [ "?" query ]]
如果端口空或?yàn)榻o出，使用80。語(yǔ)法就是，資源所在的server在host的port端口監(jiān)聽(tīng)tcp連接，而abs_path指定了請(qǐng)求資源的Request-URI。IP地址的使用只要有可能就應(yīng)該被避免（RFC1900[24]）。如果abs_path沒(méi)有出現(xiàn)在URL中，它必須作為“/”作為Request-URI（SEC5。1。2）。如果一個(gè)代理接受到不完全domain名稱(chēng)的主機(jī)名稱(chēng)，它可以用它自己的domain名稱(chēng)加進(jìn)去；如果接受到完整的，則不能改變主機(jī)名稱(chēng)。
3．2．3URI比較
當(dāng)把兩個(gè)URI比較以決定他們是否匹配，一個(gè)client應(yīng)該采用大小寫(xiě)敏感地字節(jié)對(duì)應(yīng)字節(jié)地方式比較整個(gè)URI，下面除外：
端口默認(rèn)為80，有沒(méi)有相同
host名稱(chēng)必須大小寫(xiě)不敏感
模式名稱(chēng)必須大小寫(xiě)不敏感
一個(gè)空的abs_path等同于一個(gè)“/”的abs_path
不在“reserved” and “unsafe”字符集里的字符等價(jià)與“% HEX HEX”編碼。例如
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
等價(jià)的。
3．3Data/Time 格式
3．3．1完整日期
HTTP應(yīng)用歷史上允許3中不同的DATE/TIME表示：
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
第一種多用于INTERNET標(biāo)準(zhǔn)并且代表了RFC1123[8]（RFC822[9]的更新）的固定長(zhǎng)度子集。
第二種被普遍使用，但是基于被廢棄的RFC850[12]日期格式并且缺少年度的4位表示。HTTP/1.1clients 和server解析date值就必須接受所有3種格式，雖然必須的是在HTTP頭區(qū)按RFC1123產(chǎn)生日期值。SEC19.3。
注意：date值的接收程序被鼓勵(lì)可以接受非HTTP應(yīng)用發(fā)的DATE值，這種情況經(jīng)常出現(xiàn)在通過(guò)SMTP/NNTP的代理或網(wǎng)關(guān)接收或發(fā)送信息。
3．2．2 delta秒
一些HTTP頭區(qū)允許一個(gè)時(shí)間值被一個(gè)秒的整數(shù)值來(lái)表示，十進(jìn)制，在message被接收到之后。
3．4 字符集
HTTP使用MIME描述的相同定義來(lái)定義字符集。
在這篇文檔中，術(shù)語(yǔ)字符集指使用一個(gè)或多個(gè)表把一組字節(jié)碼轉(zhuǎn)換成一組字符的方法。注意相反方向的無(wú)限制的轉(zhuǎn)化不是必需的，并不是所有的字符都在一個(gè)給定字符集中，并且一個(gè)字符集可以提供多個(gè)字節(jié)碼組合來(lái)代表一個(gè)指定字符。這個(gè)定義用來(lái)允許多種字符編碼，從簡(jiǎn)單的單表映射如US-ASCII到復(fù)雜表的轉(zhuǎn)化如ISO-2022技術(shù)。但是，和MIME字符集名稱(chēng)定義相關(guān)的定義必須完整地明確從字節(jié)碼到字符的映射。具體地說(shuō)，使用外面的相關(guān)信息來(lái)確定精確映射是不允許的。
注意：更常使用字符編碼來(lái)指字符集。但是因?yàn)镠TTP和MIME使用相同的登記，所以術(shù)語(yǔ)最好統(tǒng)一起來(lái)。
HTTP字符集用大小寫(xiě)不敏感的標(biāo)記來(lái)標(biāo)志。完整的標(biāo)記組合由IANACharacter Set registry [19]來(lái)定義。
Charset=token
雖然HTTP允許任意的TOKEN，凡是IANA Character Set registry [19]中定義的組合值必須代表其中注冊(cè)的字符集。應(yīng)用應(yīng)該僅使用那些在IANA登記中的字符集。
實(shí)現(xiàn)者要意識(shí)到IETF[38][41]。
3．4．1沒(méi)有CHARSET
一些HTTP/1。0軟件認(rèn)為沒(méi)有CHARSET參數(shù)的CONTENT-TYPE頭應(yīng)該“由接收者來(lái)猜”。這并不正確。發(fā)送者如果要阻止這種行為應(yīng)該包含一個(gè)參數(shù)即使字符集是ISO-8859-1而且如果不會(huì)迷惑接收者也應(yīng)該這樣做。
不幸的是一些更老的HTTP/1。0CLIENT不能合適地處理CHARSET參數(shù)。HTTP/1。1接收者必須采用發(fā)送者提供的該參數(shù)；而且那些可以猜的用戶(hù)端初始展示一個(gè)文檔時(shí)也必須使CONTENT-TYPE區(qū)里的字符集，而不是自己愛(ài)咋咋地。
3．5內(nèi)容編碼
內(nèi)容編碼值來(lái)指示一個(gè)可以被用到一個(gè)ENTITY上的編碼轉(zhuǎn)換。內(nèi)容編碼主要被使用來(lái)允許一個(gè)文檔被壓縮或不丟失媒體類(lèi)別信息和其他信息的轉(zhuǎn)化。ENTITY被編碼地存儲(chǔ)，直接發(fā)送，然后只被接收者解碼。
content-coding = token
token是大小寫(xiě)不敏感的。HTTP/1。1在Accept-Encoding(section 14.3)和Content-Encoding (section 14.11)使用該值。盡管該值描述了內(nèi)容編碼，更重要的是它指定了什么樣的解碼是合適的。
IANA登記了內(nèi)容編碼值。起初，登記包含了下面這些標(biāo)記：
Gzip 一個(gè)編碼樣式，由文件壓縮程序GZIP（GNU ZIP）提供，RFC1952[25]描述。這個(gè)格式是LZ77和32CRC編碼。
Compress
有UNIX文件壓縮程序“compress”來(lái)提供。格式是LZW編碼。
使用程序名字來(lái)標(biāo)志編碼格式并不理想，也將在未來(lái)的編碼中被取代。在這里使用是歷史的原因，并不是個(gè)好設(shè)計(jì)。為了向前兼容，一個(gè)應(yīng)用應(yīng)該把“x-zip”和“x-compress“認(rèn)為和”gzip“”compress”認(rèn)為是各自相同的。
Deflate
“zlib“（RFC1950[3]定義）和”deflate“壓縮機(jī)制（RFC1951[29]定義）的組合。
Identity
默認(rèn)的編碼；沒(méi)有轉(zhuǎn)化的轉(zhuǎn)化。只在Accept-Encoding頭中使用，不應(yīng)在Content-Encoding中使用。
新的內(nèi)容編碼值應(yīng)該被登記；為了允許交互性，對(duì)新值的內(nèi)容編碼算法應(yīng)該是可公共使用并足夠用來(lái)獨(dú)立實(shí)現(xiàn)，并且要滿足內(nèi)容編碼存在的初衷。
3．6傳輸編碼
傳輸編碼被用來(lái)指示一個(gè)用來(lái)保證ENTITY穿越網(wǎng)絡(luò)安全傳輸?shù)木幋a。它是MESSAGE的一個(gè)屬性并不是原始的ENETITY的。
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
parameter以屬性值對(duì)的形式存在。
parameter = attribute "=" value
attribute = token
value = token | quoted-string
所有的傳輸編碼值是大小寫(xiě)不敏感的。HTTP/1。1在TE（sec14.39）和Transfer-Encoding（SEC14。41）中使用。
只要一個(gè)傳輸編碼被應(yīng)用在一個(gè)MESSAGE-BODY中，該編碼集合必須包含“CHUNKED“，除非message因關(guān)閉連接而結(jié)束。當(dāng)”chunked“被使用，他必須是對(duì)MESSAGE-BODY的最后的編碼。絕對(duì)不能用兩次。靠這個(gè)接受者可以決定MESSAGE的傳輸長(zhǎng)度（SEC4。4）。
MEME[7]的Content-Transfer-Encoding值，用來(lái)通過(guò)7位傳輸服務(wù)來(lái)實(shí)現(xiàn)2進(jìn)制數(shù)據(jù)安全傳輸。雖然傳輸編碼類(lèi)似于這種安全傳輸，但是，安全傳輸在8位傳輸協(xié)議有一個(gè)不同的焦點(diǎn)。在HTTP傳輸中不安全的問(wèn)題主要在決定BODY的長(zhǎng)度和加密數(shù)據(jù)。
IANA登記了傳輸編碼值。最初，包含“chunked” (section 3.6.1), “identity” (section 3.6.2), “gzip” (section3.5), “compress” (section 3.5), and “deflate” (section 3.5)。新登記也應(yīng)該和內(nèi)容編碼一樣登記。
一個(gè)server,如果接收了無(wú)法處理的傳輸編碼，應(yīng)該返回501，并且關(guān)閉連接。一個(gè)server絕對(duì)不能發(fā)給HTTP1。0客戶(hù)端傳輸編碼。
3．6．1大塊的傳輸編碼
修改BODY改成一塊一塊的序列，每一個(gè)帶大小指示，帶一個(gè)可選的尾部，里面有ENTITY-HEADER區(qū)。這允許動(dòng)態(tài)地產(chǎn)生的內(nèi)容也被接收者識(shí)別組裝好。
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
chunk-size區(qū)是十六進(jìn)制數(shù)字用來(lái)表示塊的大小。編碼以一個(gè)大小為0，跟著一個(gè)空行結(jié)束的尾部的塊來(lái)作為結(jié)束。
尾部允許發(fā)送者來(lái)在MESSAGE結(jié)束出包括額外的HTTP頭區(qū)。而TRAILER頭區(qū)可以用來(lái)知識(shí)哪個(gè)頭區(qū)被包含在了一個(gè)尾部（SEC14。40）
一個(gè)server如果使用塊傳輸編碼，決不能為頭區(qū)使用尾部，除非下面至少一個(gè)是真的。
a)request包含一個(gè)TE頭區(qū)，指示在response的傳輸編碼中尾部是可以接受的。
b)server是response的origin server，尾部整個(gè)由可選元數(shù)據(jù)，而接收者可以不接收這些元數(shù)據(jù)也能使用MESSAGE。換句話說(shuō)，ORIGIN SERVER愿意接收在client傳遞過(guò)程中尾部被割掉的信息。
這個(gè)要求阻止了一些通過(guò)了HTTP/1。1（或更高版本）而被HTTP/1。0接收時(shí)出現(xiàn)的交互錯(cuò)誤。這樣就不會(huì)強(qiáng)于要求代理實(shí)現(xiàn)一個(gè)無(wú)限大小的緩存。
App19.4.6展示了一個(gè)解碼Chunked-Body的例程。
所有的HTTP/1。1應(yīng)用必須能夠接收并解碼CHUNKED傳輸編碼，并且必須忽略他們不理解的chunk-extension擴(kuò)展。
3.7媒體類(lèi)型
HTTP使用IMT[17]在Content-Type (section 14.17) and Accept (section 14.1) 頭區(qū)中提供開(kāi)放和靈活擴(kuò)展的數(shù)據(jù)類(lèi)型和類(lèi)型交互。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
參數(shù)可以以attribute/value的形式來(lái)跟隨type/subtype
ype, subtype, 和 parameter屬性名稱(chēng)都是大小寫(xiě)不敏感的。參數(shù)值可以是或不是到小寫(xiě)敏感，這取決于參數(shù)名稱(chēng)對(duì)應(yīng)的語(yǔ)法。LWS決不能在type和subtype之間被使用，也不能在attribute和它的value之間使用。參數(shù)的存在與否可能會(huì)對(duì)media-type的處理有很重要的意義，這取決于其在登記中的定義。
注意一些老的HTTP應(yīng)用不會(huì)認(rèn)出該媒體類(lèi)型參數(shù)。當(dāng)發(fā)送數(shù)據(jù)給這些應(yīng)用時(shí)，實(shí)現(xiàn)應(yīng)該只使用那些被定義要求使用的TYPE/SUBTYPE。
MEDIA-TYPE在(IANA [19])中定義。登記過(guò)程在RFC1590[17]中被概括。使用非登記的media tyoe是不提倡的。
3．7．1標(biāo)準(zhǔn)化和默認(rèn)文本
國(guó)際媒體類(lèi)型用一個(gè)標(biāo)準(zhǔn)形式登記。一個(gè)entity-body在通過(guò)HTTPmessage傳遞前必須作為相應(yīng)的標(biāo)準(zhǔn)形式存在。 “text”類(lèi)型例外，我們將在下一段說(shuō)明。
在標(biāo)準(zhǔn)形式下，“text”的子類(lèi)使用CRLF作為文本行的連接。HTTP放松了這個(gè)要求，允許在一個(gè)完整的entity-body中始終用“CR”或“LF”單獨(dú)代表行連接。HTTP應(yīng)用對(duì)于通過(guò)HTTP接收到的文本必須能夠使用CRLF，CR，LF作為行連接的代表。另外，如果文本使用的字符集并不使用13，10代表CR，LF，就象在一些多字節(jié)字符集那樣，那么，HTTP允許使用其對(duì)應(yīng)的字節(jié)碼代表該字符。這種靈活性
3．7．2多部分類(lèi)型
MIME提供了許多“multipart”類(lèi)型—用一個(gè)message封裝一個(gè)或多個(gè)entity。所有的multipart共享一個(gè)公共的語(yǔ)法（sec5.1.1-RFC2046[40]），并且必須包含一個(gè)分界參數(shù)作為media類(lèi)型值的一部分。Message本身是一個(gè)協(xié)議元素因此必須進(jìn)使用CRLF去作為跨BODY-PART的行繼續(xù)標(biāo)志。不同于在RFC2046，任何多部分類(lèi)型的MESSAGE的尾部必須是空的；HTTP應(yīng)用絕對(duì)不能傳遞尾部。（即使原先的多部分包含一個(gè)尾部）。這個(gè)限制的存在是為了保持多部分消息體的自分界性質(zhì)，就是信息體的結(jié)束使用多部分的結(jié)束作為結(jié)束。
一般情況下，HTTP對(duì)于一個(gè)多部分消息體是和其他的一樣嚴(yán)格作為有效負(fù)荷處理的。有個(gè)例外是“multipart/byteranges”（appendix19.2）當(dāng)它出現(xiàn)在206response中時(shí)，會(huì)被一些HTTP緩存機(jī)制象在sec13.5.4和14.16中描述地那樣處理。在其他情況下，一個(gè)HTTPuser agent 應(yīng)該類(lèi)似于一個(gè)MIME用戶(hù)接收一個(gè)多類(lèi)型那樣處理。除了那些在MIME語(yǔ)義中定義的那些，在每個(gè)多部分消息體中的MIME頭區(qū)對(duì)于HTTP沒(méi)有任何意義。
一般情況下，一個(gè)HTTPuser agent應(yīng)該象MIME一樣處理多部分類(lèi)型。如果一個(gè)應(yīng)用接受到一個(gè)不認(rèn)識(shí)的multipart subtype，它必須把它等同與“multipart/mixed”處理。
注意：“multipart/form-data”已經(jīng)被明確定義用來(lái)通過(guò)POST方法傳遞表單數(shù)據(jù)，RFC1867[15]。
3．8產(chǎn)品標(biāo)記
產(chǎn)品標(biāo)記被用來(lái)允許通訊應(yīng)用來(lái)通過(guò)軟件名稱(chēng)和版本來(lái)標(biāo)志他們自己。大多數(shù)使用產(chǎn)品標(biāo)記的區(qū)也使用子產(chǎn)品來(lái)形成被列出的應(yīng)用的重要組成部分，它們以空格分開(kāi)。按照其重要程度來(lái)有序列出。
product = token ["/" product-version]
product-version = token
例如：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
產(chǎn)品標(biāo)記應(yīng)該言短意賅。它們絕對(duì)不能被用來(lái)做廣告或其他不重要的信息。雖然任何的標(biāo)記字符可以出現(xiàn)在一個(gè)product-version里，這些個(gè)字符應(yīng)該只用來(lái)標(biāo)記版本。（例如，接續(xù)的版本好應(yīng)該只在產(chǎn)品版本部分不同）。
3.9屬性值
HTTP content negotiation（SEC12）使用短浮點(diǎn)數(shù)來(lái)標(biāo)記各種negotiable參數(shù)的重要性（權(quán)重）。一個(gè)權(quán)重回被標(biāo)準(zhǔn)化成一個(gè)>0并且<1的數(shù)。如果一個(gè)參數(shù)是0的質(zhì)量值，那這個(gè)參數(shù)的內(nèi)容是不被客戶(hù)端所接受的。HTTP/1。1應(yīng)用絕對(duì)不能產(chǎn)生多于小數(shù)點(diǎn)后3位的數(shù)。用戶(hù)對(duì)他們的值的配置也應(yīng)該限于此
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
其實(shí)這個(gè)名字本身容易引起誤解，因?yàn)槠渲祪H僅代表要求質(zhì)量的相對(duì)級(jí)別。
3.10語(yǔ)言標(biāo)記
一個(gè)語(yǔ)言標(biāo)記被用來(lái)標(biāo)志人們說(shuō)的語(yǔ)言。當(dāng)然計(jì)算機(jī)語(yǔ)言肯定不被包含在內(nèi)。HTTP在Accept-Language 和 Content-Language區(qū)使用語(yǔ)言標(biāo)記。
HTTP語(yǔ)言標(biāo)記的語(yǔ)法和登記和RFC1766[1]定義的類(lèi)似。總之，一個(gè)語(yǔ)言標(biāo)記是由1或多個(gè)部分組成：一個(gè)主語(yǔ)言標(biāo)記和一個(gè)可能的空子標(biāo)記序列：
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
空格在標(biāo)記中不被允許并且所有的標(biāo)記都是大小寫(xiě)不敏感的。語(yǔ)言標(biāo)記命名空間在IANA中管理。例如：
en, en-US, en-cockney, i-cherokee, x-pig-latin
任何2字母的主標(biāo)記是一個(gè)ISO-639語(yǔ)言縮寫(xiě)，而任何2字母的初始子標(biāo)記是一個(gè)ISO-3166國(guó)家碼。（后3個(gè)沒(méi)有登記，最后一個(gè)不會(huì)被允許）。
3．11實(shí)體標(biāo)記
實(shí)體標(biāo)記用來(lái)比較來(lái)自相同的去請(qǐng)求資源的兩個(gè)或多個(gè)實(shí)體。HTTP/1。1在ETag (section 14.19), If-Match (section 14.24), If-None-Match (section 14.26), 和If-Range
使用實(shí)體標(biāo)記。
如何定義以及怎么作為緩存校驗(yàn)來(lái)比較在sec13.3.3中描述。
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
如果同一資源的兩個(gè)ENTITY具有相同的位集可以共享“strong entity tag”。
而由一個(gè)"W/" 前綴表示的“weak entity tag”標(biāo)記的tag，如果是相等的并可以在語(yǔ)義上無(wú)修改地互相取代，那么可以共享一個(gè)標(biāo)記。只能用來(lái)弱比較。
在一個(gè)給定resource中的對(duì)應(yīng)實(shí)體必須保持實(shí)體標(biāo)記具有唯一性。但是如果是不同URI得到的實(shí)體可以有相同標(biāo)記值，但不表示這些實(shí)體是等價(jià)的。
3．12范圍單位
HTTP/1。1允許一個(gè)client只是response實(shí)體的部分被包含在response中。HTTP/1。1在Range (section 14.35) 和Content-Range (section 14.16)中使用范圍單位。一個(gè)實(shí)體能夠根據(jù)各種結(jié)構(gòu)單位分成多個(gè)范圍
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
在HTTP/1。1定義的唯一的范圍單位是”byte”。HTTP/1。1的實(shí)現(xiàn)可以忽略其他范圍定義。HTTP/1。1被設(shè)計(jì)成允許那些不必知道范圍單位的應(yīng)用的存在。