rfc1945-http1.0自譯本-(4) (轉)

rfc1945-http1.0自譯本-(4) (轉)[@more@] 

3.2  統一資源標識（UnifoRe ntifiers）

 :namespace prefix = o ns = "urn:schemas--com::office" />

  URI有許多名字，如WWW地址、通用標識（Universal Document Identifiers）、通用資源標識（Universal Resource Identifiers [2]），以及最終的統一資源定位符（Uniform Resource Locators (URL) [4]）和統一資源名（URN）。在涉及HTTP以前，URI用簡單格式的字串描述－名字、位置、或其它特性，如資源。

 

3.2.1 一般語法（General Syntax）

  在HTTP中URI可以用絕對形式表示，也可用相對於某一基本URI[9]的形式表示，具體取決於它們的使用方式。這兩種形式的不同在於絕對URI總是以方法名稱後跟“：”開頭。

 

  URI    = ( absoluteURI | relativeURI ) [ "#" fragment ]

 

  absoluteURI  = scheme ":" *( uchar | reserved )

 

  relativeURI  =_path | abs_path | rel_path

 

  net_path  = "//" net_loc [ abs_path ]

  abs_path  = "/" rel_path

  rel_path  = [ path ] [ ";" params ] [ "?" query ]

 

  path  = fsegment *( "/" segment )

  fsegment  = 1*pchar

  segment   = *pchar

 

  params  = param *( ";" param )

  param  = *( pchar | "/" )

 

  scheme  = 1*( ALPHA | DIGIT | "+" | "-" | "." )

  net_loc  = *( pchar | ";" | "?" )

  query  = *( uchar | reserved )

  fragment  = *( uchar | reserved )

 

  pchar  = uchar | ":" | "@" | "&" | "=" | "+"

  uchar  = unreserved | escape

  unreserved  = ALPHA | DIGIT | safe | extra | national

 

  escape  = "%" HEX HEX

   reserved  = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"

  extra  = "!" | "*" | "'" | "(" | ")" | ","

  safe  = "$" | "-" | "_" | "."

  unsafe  = CTL | SP | | "#" | "%" | ""

  national  =

 

Berners-Lee, et al  Informational  [Page 14]

 

  reserved, extra, safe, and unsafe>

  權威的URL語法及語義資訊請參見1738[4]和RFC1808[9]。上面所提到的BNF中包括了合法URL中不允許出現的符號（RFC1738），因為HTTP並沒有限制為只能用非保留字符集中的字元來表示地址路徑，而且HTTP也可能接收到RFC1738沒有定義的URI請求。

 

3.2.2 http URL

 

“http”表示要透過來定位網路資源。本節定義了HTTP URL的語法和語義。

 

  http_URL  = "http:" "//" host [ ":" port ] [ abs_path ]

 

host  =

，見RFC1123，2.1節定義>

 

  port  = *DIGIT

 

  如是埠為空或沒指定，則預設為80埠。對於絕對路徑的URI來說，擁有被請求的資源的伺服器主機透過偵聽該埠的TCP連線來接收該URI請求。如果URL中沒有給出絕對路徑，要作為請求URI（參見5.1.2節）使用，必須以“/”形式給出。

 

  注意：雖然HTTP協議獨立於傳輸層協議，http URL只是標識資源的TCP位置，而對於非TCP資源來說，必須用其它的URI形式來標識。

 

  規範的HTTP URL形式可透過將主機中的大寫字元轉換成小寫（主機名是大小寫敏感的）來獲得。如果埠是80，去掉冒號及埠號，並將空路徑替換成“/”。

 

3.3  Date/Time 格式（Date/Time Formats）

 

  出於歷史原因，HTTP/1.0應用允許三種格式來表示時間戳：

 

  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

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 15]

 

  第一種格式是首選的Internet標準格式，表示方法長度固定（RFC1123[6]）。第二種格式在普通情況下使用，但是它是基於已經廢棄的RFC850[10]中的日期格式，而且年不是用四位數字表示的。HTTP/1.0 客戶端及伺服器端在解析日期時可識別全部三種格式，但是它們不可以產生第三種時間格式(asctime) 。

  注意：對於接收到由非HTTP應用產生的日期資料時，提倡對接收到的日期值進行填充。這樣做是因為，在某些時候，代理或閘道器可能透過SMTP或NNTP來獲取或傳送訊息。

  所有的HTTP/1.0 date/timp時間戳必須用世界時間（Universal Time，UT），即格林威治時間來表示（Greenwich Mean Time，GMT），沒有任何修改的餘地。前面的兩種格式用了“GMT”表示時區，在讀ASC表示的時間時，也應假定是這個時區。

 

HTTP-date = rfc1123-date | rfc850-date | asctime-date

 

rfc1123-date  = wkday "," SP date1 SP time SP "GMT"

rfc850-date  = weekday "," SP date2 SP time SP "GMT"

asctime-date  = wkday SP date3 SP time SP 4DIGIT

date1  = 2DIGIT SP month SP 4DIGIT

  　; day month year (e.g., 02 Jun 1982)

date2  = 2DIGIT "-" month "-" 2DIGIT

  ; day-month-year (e.g., 02-Jun-82)

date3  = month SP ( 2DIGIT | ( SP 1DIGIT ))

   ; month day (e.g., Jun  2)

time   = 2DIGIT ":" 2DIGIT ":" 2DIGIT

  ; 00:00:00 - 23:59:59

wkday  = "Mon" | "Tue" | "Wed"

  | "Thu" | "Fri" | "Sat" | "Sun"

weekday  = "Monday" | "Tuesday" | "Wednesday"

  | "Thursday" | "Friday" | "Saturday" | "Sunday"

month  = "Jan" | "Feb" | "Mar" | "Apr"

  | "May" | "Jun" | "Jul" | "Aug"

  | "Sep" | "Oct" | "Nov" | "Dec"

注意：HTTP要求只能在協議流中使用data/time時間戳格式，不要求客戶端及伺服器端在描述、請求登入等情況下使用這類格式。

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 16]

3.4  字符集（Character Sets）

 

  HTTP所使用的字符集定義和描述MIME時用的相同：

本文件用字符集（character set）來指明利用一個或多個表將順序位元組轉換成順序字元的方法。注意，不需要其它方向的無條件轉換，因為不是所有的字元都可以用給定字符集來表示，同時，一個字符集也可能提供一種以上的位元組順序來表示一種特殊的字元。這種定義傾向於允許不同型別的字元編碼透過簡單的單表對映來實現，如，從表US-ASCII切換到複雜表如ISO2202。實際上，與MIME字符集名相關的定義必須完整指定從位元組到字元的對映，特別是不允許透過利用外部資訊來確定精確的對映。

 

注意：術語字符集（character set）歸於字元編碼（character encoding）。事實上，由於HTTP與MIME共同使用同樣的註冊，所以其術語也應一致。

 

HTTP字符集由大小寫敏感的符號組成。全部的符號定義參見IANA字符集註冊[15]。因為註冊處不會為每個字符集單獨定義一套符號，所以我們在這看到的字符集名大多是與HTTP實體使用相關的。這些在RFC 1521 [5] 中註冊的字符集，即US-ASCII [17] 及ISO-8859 [18]字符集，還有一些其它字符集被強烈建議在MIME字符集引數內部使用。

 

charset = "US-ASCII"

  | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"

  | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"

  | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"

  | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"

  | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"

  | token

 

雖然HTTP允許使用專用符號做為字符集值，但是任何在IANA字符集登錄檔[15]中有預定義值的符號都必須表明其所屬的字符集。應用應當將其對字符集的使用限制在IANA登錄檔規定的範圍之內。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 17]

 

實體主體的字符集如果屬於US-ASCII 或ISO-8859-1字符集，則勿需標記，否則，應當用主體字元編碼方式中的最基本命名來標記。

 

3.5  內容譯碼（Content Codings）

  內容譯碼值用於指示對資源進行的編碼轉換。內容譯碼主要用於將經過、等操作的檔案進行還原，使其保持其原來的介質型別。典型情況下，經過編碼儲存的資源只能經過解碼或類似的操作才能還原。

content-coding = "x-" | "x-compress" | token

  注意：出於對未來相容性的考慮，HTTP/1.0應用應將"gzip" 和"compress" 分別與 "x-gzip"和"x-compress"對應起來。

  所有的內容譯碼值都是大小寫敏感的。HTTP/1.0在內容編碼（10.3節）頭域中使用內容譯碼值。雖然該值描述的是內容譯碼，但更為重要的是，它指明瞭應當用什麼機制來進行解碼。注意，單獨的可能有能力實現對多種格式編碼的解碼。

  在這段文字中，提到了兩個值：

x-gzip

檔案壓縮程式"gzip" ( zip，由Jean-loup Gailly開發)的編碼格式。該格式屬於典型的帶有32位CRC 校驗的Lempel-Ziv譯碼 (LZ77)。

x-compress

檔案壓縮程式"compress"的編碼格式，該格式適用於LZW（Lempel-Ziv-Welch）譯碼。

注意：用程式名來標識編碼格式的做法不是很理想，在將來可能不會繼續這樣做。現在之所以這樣做是出於歷史的原因，並非良好的設計。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 18]

 

3.6  介質型別（Media Types）

 

  HTTP在Content-Type header域（10.5節）中使用Internet介質型別[13]，用以提供開放的可擴充套件的資料型別。

media-type  = type "/" subtype *( ";" parameter )

type     = token

subtype    = token

 

  引數可參照屬性/值對的方式，用型別/子型別的格式來寫。

 

Parameter  = attribute "=" value

Attribute    = token

Value    = token | quoted-string

 

  其中，型別、子型別、引數屬性名是大小寫敏感的。而引數值不一定是大小寫敏感的，這得看引數名的語法而定。在型別和子型別、屬性名和屬性值之間不能有LWS（空格）。當接收到不能識別的介質型別的引數時，使用者代理應當忽略它們。

  一些老的HTTP應用不能識別介質型別引數，所以HTTP/1.0的應用程式只能在定義訊息內容時使用介質引數。

  介質引數（Media-type）值用Internet授權分配數字（Internet Assigned Number  Authority ，IANA [15]）註冊。介質型別註冊過程請參見RFC1590[13]。不鼓勵使用未註冊的介質型別。

 

3.6.1標準及文字預設（Canonicalization and Text Defaults）

  Internet介質型別是用規範形式註冊的。一般來說，在透過HTTP協議傳輸實體主體（Entity-Body）之前，必須先將其表示成適當的規範格式。如果主體用使用了一種Content-Encoding進行編碼，下面的資料在編碼前必須轉換成規範形式：

  “text”型別的介質子型別在規範形式中使用CRLF做為文字行中斷。實際上，為和實體主體（Entity body）內的使用方式保持一致，HTTP允許傳輸純以CR或LF單獨表示行中斷的文字介質。HTTP應用程式必須將其透過HTTP方式接收到的文字介質中的CRLF、CR、LF看做是行中斷符。

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 19]

 

  另外，如果文字介質的字符集沒有使用位元組13和10做為CR和LF，象一些多位元組字符集，HTTP允許使用該字符集指定的任何順序的位元組替代CR和LF做為行中斷，這種行中斷的靈活運用方式僅可於實體主體（Entity-Body）中。一個純CR或LF不應在任何HTTP控制結構（如標題域-header field和多塊分界線-multipart boundaries）中替代CRLF。

  引數"charset"在定義資料的字符集（3.4節）時，與一些介質型別一起使用。當傳送方沒有顯式給出字元引數時，HTTP在接收時將”text”的介質子型別定義為預設值”ISO-8859-1”。”ISO-8859-1”字符集或其子集以外的資料必須要標記其相應的字符集值，這樣可以保證接收方能正確地對其進行解析。

  注意：許多當前HTTP伺服器提供的資料使用”ISO-8859-1”以外的其它字符集，而且也沒有正確的進行標記，這種工作方式限制了互操作性，建議不要採用。做為一種補救方法，一些HTTP使用者代理提供了配置選項，使使用者可以在字符集引數沒指定的情況下，自行更改預設的介質型別解釋方式。

 

3.6.2 多部分型別（Multipart Types）

 

 

  MIME提供了多部分（"multipart"）型別的數字――在一個單獨的訊息實體主體（Entity-Body）內可以封裝幾個實體（entities）。雖然使用者代理可能需要了解每種型別，從而可以正確解釋每部分主體的意圖，但是在IANA[15]的多部分型別（multipart types）註冊中卻找不到專為HTTP/1.0所指定的內容。HTTP使用者代理只得自己來做接收多部分型別的工作，其過程和行為與MIME使用者代理是相同或相似的。HTTP伺服器不應假定HTTP客戶端都有能力處理多部分型別。

 

  所有的多部分型別都使用通用的語法，而且必須在介質型別值部分包括邊界引數（boundary parameter）。訊息的主體是其自身，做為協議元素，它必須只使用CRLF做為段間（body-parts）的行中斷符。多段主體（Multipart body-parts）中可能包括對各段有重要意義的HTTP標題域。

 

3.7  產品標識（Product Tokens）

  是通訊應用程式用來標識其自身的一個簡單符號，常和任意字母及版本描述一起使用。大多數產品標識也將其產品的重要組成部分的版本號一起列出，中間用空格分隔。

 

 

 

 

 

 

 

 

 

 

 

 

 

Berners-Lee, et al  Informational  [Page 20]