HTTP 1.1 学习笔记 3 协议参数

1.HTTP Version

HTTP使用"<major>.<minor>”数字模式来表示协议的版本。

在HTTP协议发生变化，且该变化不改变普遍的消息解析算法，但改变增加了消息的语义或者增加了协议的特性时，<minor>数字增长；如果变化改变了协议中消息的格式，那么<major>数字增长。

格式：

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

注：major或者minor数字中的前导字符必须被接收者忽视，且必须不能被发送。

一个应用程序的HTTP版本是该应用程序支持的最高版本。

2.URI (Uniform Resource Identifiers)

格式：

HTTP_URL = "http:" "//" host [":" port ] [abs_path [ "?" query]]

port不存在，默认80；abs_path不存在，默认"/"。query是查询字符串。 URI比较时，大小写不敏感。

3.Date/Time Formats

HTTP应用程序允许3种不同的时间格式：

1.Sun, 06 Nov 1994 08:44:44 GMT; RFC 822, Updated by RFC 1123,这是标准时间

2.Sunday, 06-Nov-94 09:44:44 GMT; RFC 850,用的比较多，但 RFC1036认定该格式已过时

3.Sun Nov 6 08:39:33 1994;ANSI C's asctime() 格式

解析时间格式的client，server必须同时支持3种格式。

所有的HTTP 日期时间戳必须使用GMT（Greenwich Mean Time）表示。

格式：

HTTP-date = rfc1123-date | rfc850-date | accctime-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

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

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

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

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"



4.Character Set

HTTP 使用同MIME中定义相同的术语 ”character set"， 术语字符集，指一个方法，函数使用一张或者多张表格将字节流转换成字符串。

反向转换不是绝对的，因为一个给定的字符集中不一定包含一个特定的字符，并且一个字符集可能提供多余一个的字节流来表述一个特定字符。

HTTP 字符集由大小写不敏感的字符定义：

charset = token

这里的token表示US-ASCII（0-127）中除去控制字符（0-31）以及分隔符以外的所有字符组成的字符串。

分隔符包括“(” , “)” , "<" , ">" , "@" , "," , ":" , "\","\"', "/", "[", "]", "?", "=", "{", "}", " ", "\t"等。

HTTP韵询任意的token作为一个charset 值，但是应用程序应当将token的范围限制为IANA定义的范围内。

注意：一些HTTP1.1接收者必须遵照发送方提供的字符集，如果接收方支持该字符集，那在初始化显示文档时应当使用该字符集来显示，

而不是靠猜测；如果不支持该字符集，那只能按照一定的规则来猜测文档使用的字符集。



5.Content Codings

该值指明了已经或者可以被施加于实体（entity）的编码转换方式。内容编码主要用于压缩文档而不丢失其包含的媒体类型以及任何信息。

通常，实体(entity)以被编码的形式存储，传输，并只被接收方解码。格式：

content-coding = token

注：所有的内容编码值都不是大小写敏感的。HTTP/1.1在Accept-Encoding以及Content-Encoding两个字段中使用了内容编码值。

当下，有四种主流编码方式：

1.gzip， 来自程序"gzip"（GNU zip）

2.compress, 该格式由UNIX文件压缩程序"compress“产生。这是一个自适应的LZW(Lempel-Ziv-Welch)编码。

3.deflate, "zlib" format

4.identity, 默认编码方式，不使用任何转换。这种编码方式只在Accept-Encoding头使用，而且不应在Content-Encoding头中使用 。



6.Transfer Codings

为了确保在网络中安全传输，传输编码值用于指明已经，可以，或者可能需要被用于实体body(entity-body)的一种转换编码。

Transfer codings 同Content codings的不同在于，前者是一条信息的一个属性，而不是原始实体的一个属性。

注：实体被包含于信息，一个实体是一条信息的一部分，信息是实体的载体。

格式：

transfer-coding = "chunked" | transfer-extension

transfer-extension = token *( ";" parameter )

参数以属性-值对的格式展示：

parameter = attribute "=" value

attribute = token

value = token | quoted-string

所有的transfer-coding 值都是大小写不敏感的。HTTP/1.1在TE以及Transfer-Encoding头字段中使用该编码值。

TE字段是HTTP request-header中使用的字段，该字段用以通知对方（请求接收方）请求发送方愿意，能接受response中的何种transfer-codings以及是否愿意接受chunked传输编码中的trailer字段。格式：

TE = "TE" ":" #(t-codings)

t-codings = "trailers" | (transfer-extension[accept-params])

关键词trailer的出现表明客户端（请求发送方）愿意接受chunked传输编码中的trailer字段。该关键词本身不表示一种transfer-coding，是一个保留值。

例：

TE:deflate

TE:

TE: trailers, deflate;q=0.5

注：TE头字段只用于即时链接（immediate connection）。因此，任何时候，只要TE字段出现在一条信息中，那么必须在Connection头字段中提供传输编码相关的关键词。

服务端根据TE字段使用以下规则来测试一种传输编码是否是被接受的：

1.”chunked“方式是永远被接受的，因为它不使用任何编码。如果”trailer“关键词出现在TE头字段中，那么客户端代表它自己以及下流客户端表示它愿意接受以"chunked"方式编码的response中的trailer字段。隐含的意思是，任何下流客户端都愿意接受trailer字段。

2.如果正在测试的一种传输编码是TE字段中列出的传输编码中的一个，那么该编码是被客户端接受的，除非TE中列出的该编码值后面紧跟了一个q值，且值为0。（0表明不被接受的）

3.如果多种传输编码是被接受的，那么拥有最大非0q值的的传输编码将被优先使用。"chunked"方式的q值总是等于1.

如果TE字段值为空或者没有TE字段，那仅被接受的传输编码是"chunked"，一条没有编码的信息总是被接受的。



7.Transfer Coding - Chunked

为了将一条信息分割成多个chunks来传输，"chunked"编码方式修改一条信息的body部分，每部分都有它自己的大小指示值，紧跟其后是一个可选的包含实体头（entity-header）字段的trailer。这可以使接收方可以识别它是否已经接受了一条完整的信息。

格式：

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)

任何一个大小为0的chunk表明chunked编码到此结束。

格式中的trailer允许发送方在消息结尾处包含附加的HTTP头字段。Trailer头字段可被用来指明trailer中包含了哪些头字段，这样接收方可以提前知道trailer中包含了哪些头字段。

Trailer头字段 格式：

Trailer = "Trailer" ":" 1#field-name

如果Trailer头字段不存在，那trailer不应当包含任何头字段。另外，Trailer头字段必须不能包含Transfer-Encoding,Content-Length,Trailer这三个头字段。

在response中使用chunked作为传输编码的服务端只能在以下情况为真时使用trailer：

1.服务端接受到的request中包含TE头字段，且该字段指明"trailer"在response的传输编码是被接受的。

2.当前服务端是产生response的原始服务端，trailer段包含所有的可选元数据，同时，接收方可以在不接受这些元数据的情况下使用这条消息。换句话说，原始服务端接受trailer字段在消息传达到客户端的路径中被静默丢弃的可能性。

当一条消息被HTTP/1.1或者更高版本的HTTP协议接收，然后又被转发到HTTP/1.0的接收方时，上述2点需求阻止了一种互操作性的失败。这避免了为了同原来的协议兼容而可能不得不使用无限缓存的情形。



8.Media Types

HTTP为了支持开放的，可扩展的数据类型以及类型协商，在Content-Type与Accept头字段中使用互联网媒体类型。

格式：

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

type = token

subtype = token

参数可能以属性值对待形式跟在type/subtype后。类型，子类型以及参数属性的名字都是大小写不敏感的，根据参数名字的语法，参数值可能或者可能不是大小写敏感的。LWS必须不能在type与subtype之间使用，也不能在属性以及属性值之间使用。

注：一些老的HTTP应用程序不认识媒体类型参数。故发送数据给那些老的HTTP应用程序是，只能在需要的情况下发送媒体类型参数。



9.Canonicalization and Text Defaults

互联网媒体类型以标准类型注册，除”text“类型之外，一个通过HTTP消息传输的entity-body必须在传输前转换成适当的标准形式（”text“类型无需转换）。标准形式中，”text“类型的媒体子类型使用CRLF作为文本的换行符。HTTP放松了这一要求，允许传输的文本媒体使用独立的CR或者LF表示一个换行符，前提是在整个entity-body中这种情况都是统一的。即不能一会是CR作为换行符，一会是LF作为换行符。

HTTP允许使用字符集中任何能表示CR或者LF的等同字节流作为换行符，这种关于换行符的灵活性只用于entity-body中的文本媒体；在任何HTTP控制结构（header fields and multipart boundaries）中，一个单独的CR或者LF必须不能被CR LF替代。

如果entity-body使用了一种content-coding，那么内部数据必须在被编码之前用上述定义的形式存在。

一些媒体类型中使用”charset“参数来定义数据的字符集。当发送方没有明确提供charset参数时，通过HTTP接受到的"text"类型的媒体子类型使用默认的“ISO-8859-1”字符集。

数据字符集不使用默认的“ISO-8859-1”的，必须提供一个适当的字符集值。



10.Multipart Types

MIME 为多种复合类型做了准备工作。复合类型是指在一个单独的消息体中封装了一个或者多个实体。消息体本身是一个协议元素，因此必须使用且只能使用CRLF来表 示body-parts之间的换行。不同于RFC2046，任何的复合消息的结尾（epilogue）都必须为空；HTTP应用程序必须不能传输结尾 （epilogue），即使原始的复合消息包含一个epilogue。

一般地，HTTP不同复合消息体（multipart message-body）与其他媒体类型做区别对待，都将它们看作负载（payload）。唯一的例外是返回码为206（partial content）的response中类型为“multipart/byteranges"的媒体类型，这种响应会被一些HTTP缓存机制解析，缓存。其 他所有接受到复合类型的情形中，HTTP用户代理应当遵循相同或者相似于MIME用户代理的行为。除MIME定义的语法外，每部分复合消息体中的MIME 头字段对HTTP没有任何意义。如果接受到不能识别的复合子类型，应用程序必须将它作为”multipart/mixed"类型的等同类型来对待。

注：为了携带适合通过POST请求方式传输的表单数据，“multipart/form-data"类型已经被特殊定义。见RFC1867[15]。

11.Product Tokens

产品标识被用于允许通信的应用程序通过软件名称和版本来区分它们自身。按照惯例，产品以对识别应用程序的重要性顺序来列出。

格式：

product = token ["/" product-version]

product-version = token

举例：

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

12.Quality Valules

HTTP content negotiation 使用short ”float point"数字来指示众多的可协商参数的相对重要性（权重）。权重值标准化为一个0与1之间的实数，0最小，1最大。

如果q=0，表示与该参数有关的内容是不被客户端接受的。该值小数点后位数最多不能超过3位。

格式：

qvalue = ("0" [ "." 0*3DIGIT] ) | ("1" ["." 0*3("0")])



13.Language Tags

标识一种自然语言。HTTP在Accetp-Language与Content-Language字段中使用language tags.

格式：

language-tag = primary-tag *( "-" subtag)

primary-tag = 1*8ALPHA

subtag = 1*8ALPHA

tag之间不允许存在空格，所有的tag都是大小写不敏感的。language tags的命名空间由IANA管理。示例tag:

en, en-US, en-cockney, i-cherokee, x-pig-latin



14.Entity Tags

被用来比较2个或者多个来自相同请求资源的实体。HTTP/1.1在ETag, If-Match, If-None-Match 以及 If-Range头字段中使用entity tags。

entity tag 包含一个不透明的字符串，而且可能以弱标识（weakness indicator）作为前缀。

格式：

entity-tag = [weak] opaque-tag

weak = "W/"

opaque-tag = quoted-string

"strong entity tag" 只有同一个资源的两个实体在字节序上等同时，MAY be shared。

"weak entity tag"以“W/”前缀表示，只有同一个资源的两个实体可以被互相替换并且不会在语义上产生重大改变时，MAY be shared。只能被用与弱比较。

entity tag在一个特定的资源相关联的所有entity的所有版本中必须是唯一的。

15.Range Units

HTTP/1.1允许client只请求一个response中的一部分entity。HTTP/1.1在Range和Content-Range头字段中使用range units。

格式：

range-unit = bytes-unit | other-range-unit

bytes-unit = "bytes"

other-range-unit = token

HTTP/1.1唯一定义的range unit就是“bytes"。