HTTP/1.1协议RFC标准详解：互联网应用基石

5星 · 超过95%的资源需积分: 0 182 浏览量更新于2024-07-26 收藏 538KB PDF 举报

HTTP/1.1协议是互联网领域的一项核心标准，由网络工作小组（Network Working Group）成员R. Fielding等人于1999年6月提出，并被RFC 2616文档详细定义。该协议是Hypertext Transfer Protocol（超文本传输协议）的第1.1版本，其目标是设计一个适用于分布式、协作和超媒体信息系统的基础应用层协议。HTTP/1.1强调了通用性、无状态特性，使得它能够扩展用于多种任务，而不仅仅是支持超文本链接。该协议的主要特点是： 1. **状态less**: HTTP/1.1是一种无状态协议，这意味着服务器不会保存与特定客户端会话相关的任何信息。这种设计使得服务器能够高效地处理大量并发连接，降低了服务器的内存需求。 2. **请求方法**：HTTP/1.1引入了新的请求方法，如`PATCH`, `COPY`, `DELETE`, `HEAD`等，提供了更丰富的数据操作手段。这使得协议可以适应不同的应用场景，如对象存储和数据更新等。 3. **错误代码**：标准化了错误码体系，使得客户端和服务器之间能够更准确地传递错误信息，提高了通信的可理解和可操作性。 4. **头部扩展**：HTTP/1.1允许通过头部字段（如`Cache-Control`, `If-Modified-Since`, `Content-Type`等）来实现更精细的数据控制和优化性能。例如，`Cache-Control`允许缓存机制的设置，`If-Modified-Since`则用于检查文档是否已更改。 5. **持续连接（Persistent Connections）**：为了减少握手次数，提高效率，HTTP/1.1引入了持久连接机制，即在一次TCP连接上进行多个请求和响应，直到连接关闭。 6. **管道化（Pipelining）**：允许客户端同时发送多个请求，无需等待每个请求的响应完成，从而提高了数据传输的效率。 7. **Keep-Alive**：在持久连接的基础上，HTTP/1.1还引入了Keep-Alive选项，使得服务器可以在一段时间内保持连接，便于后续请求的快速响应。 8. **代理和缓存支持**：明确规范了代理服务器和缓存机制的行为，促进了网络资源的共享和性能提升。 9. **标准和标准化状态**：HTTP/1.1被指定为互联网标准跟踪协议，其状态和标准化过程参考互联网官方协议标准（STD 1）。所有使用该协议的实体都应遵循当前版本。这份RFC文档不仅提供了HTTP/1.1的核心概念和功能，还为后续的协议发展和演进奠定了基础。对于开发人员、网络管理员和研究者来说，深入理解HTTP/1.1是构建现代Web应用程序和优化网络性能的关键。

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 16]

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

Note: HTTP requirements for the date/time stamp format apply only to their usage within the protocol

stream. Clients and servers are not required to use these formats for user presentation, request logging, etc.

3.3.2 Delta Seconds

Some HTTP header fields allow a time value to be specified as an integer number of seconds, represented in

decimal, after the time that the message was received.

delta-seconds = 1*DIGIT

3.4

Character Sets

HTTP uses the same definition of the term “character set” as that described for MIME:

The term “character set” is used in this document to refer to a method used with one or more tables to

convert a sequence of octets into a sequence of characters. Note that unconditional conversion in the other

direction is not required, in that not all characters may be available in a given character set and a character

set may provide more than one sequence of octets to represent a particular character. This definition is

intended to allow various kinds of character encoding, from simple single-table mappings such as US-

ASCII to complex table switching methods such as those that use ISO-2022’s techniques. However, the

definition associated with a MIME character set name MUST fully specify the mapping to be performed

from octets to characters. In particular, use of external profiling information to determine the exact mapping

is not permitted.

Note: This use of the term “character set” is more commonly referred to as a “character encoding.”

However, since HTTP and MIME share the same registry, it is important that the terminology also be

shared.

HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA

Character Set registry [19].

charset = token

Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within

the IANA Character Set registry [19] MUST represent the character set defined by that registry. Applications

SHOULD limit their use of character sets to those defined by the IANA registry.

Implementors should be aware of IETF character set requirements [38] [41].

3.4.1 Missing Charset

Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean

“recipient should guess.” Senders wishing to defeat this behavior MAY include a charset parameter even when the

charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.

Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1

recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to

“guess” a charset MUST use the charset from the content-type field if they support that charset, rather than the

recipient’s preference, when initially displaying a document. See section 3.7.1.

3.5

Content Codings

Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content

codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing

the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded

form, transmitted directly, and only decoded by the recipient.

content-coding = token

All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding

(section 14.3) and Content-Encoding (section 14.11) header fields. Although the value describes the content-

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 17]

coding, what is more important is that it indicates what decoding mechanism will be required to remove the

encoding.

The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the

registry contains the following tokens:

gzip An encoding format produced by the file compression program “gzip” (GNU zip) as described in RFC 1952

[25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.

compress

The encoding format produced by the common UNIX file compression program “compress”. This format is

an adaptive Lempel-Ziv-Welch coding (LZW).

Use of program names for the identification of encoding formats is not desirable and is discouraged for

future encodings. Their use here is representative of historical practice, not good design. For compatibility

with previous implementations of HTTP, applications SHOULD consider “x-gzip” and “x-compress” to be

equivalent to “gzip” and “compress” respectively.

deflate

The “zlib” format defined in RFC 1950 [31] in combination with the “deflate” compression mechanism

described in RFC 1951 [29].

identity

The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only

in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.

New content-coding value tokens SHOULD be registered; to allow interoperability between clients and servers,

specifications of the content coding algorithms needed to implement a new value SHOULD be publicly available and

adequate for independent implementation, and conform to the purpose of content coding defined in this section.

3.6 Transfer Codings

Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be

applied to an entity-body in order to ensure “safe transport” through the network. This differs from a content coding

in that the transfer-coding is a property of the message, not of the original entity.

transfer-coding = "chunked" | transfer-extension

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

Parameters are in the form of attribute/value pairs.

parameter = attribute "=" value

attribute = token

value = token | quoted-string

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (section

14.39) and in the Transfer-Encoding header field (section 14.41).

Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include “chunked”,

unless the message is terminated by closing the connection. When the “chunked” transfer-coding is used, it MUST

be the last transfer-coding applied to the message-body. The “chunked” transfer-coding MUST NOT be applied

more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message

(section 4.4).

Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME [7], which were

designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different

focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty

in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.

The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the

registry contains the following tokens: “chunked” (section 3.6.1), “identity” (section 3.6.2), “gzip” (section

3.5), “compress” (section 3.5), and “deflate” (section 3.5).

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 18]

New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens

(section 3.5).

A server which receives an entity-body with a transfer-coding it does not understand SHOULD return 501

(Unimplemented), and close the connection. A server MUST NOT send transfer-codings to an HTTP/1.0 client.

3.6.1 Chunked Transfer Coding

The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own

size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced

content to be transferred along with the information necessary for the recipient to verify that it has received the full

message.

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)

The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by

any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.

The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer

header field can be used to indicate which header fields are included in a trailer (see section 14.40).

A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least

one of the following is true:

a) the request included a TE header field that indicates “trailers” is acceptable in the transfer-coding of the

response, as described in section 14.39; or,

b) the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the

recipient could use the message (in a manner acceptable to the origin server) without receiving this

metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might

be silently discarded along the path to the client.

This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later)

proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have

necessitated a possibly infinite buffer on the proxy.

An example process for decoding a Chunked-Body is presented in appendix 19.4.6.

All HTTP/1.1 applications MUST be able to receive and decode the “chunked” transfer-coding, and MUST ignore

chunk-extension extensions they do not understand.

3.7

Media Types

HTTP uses Internet Media Types [17] in the Content-Type (section 14.17) and Accept (section 14.1) header

fields in order to provide open and extensible data typing and type negotiation.

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

type = token

subtype = token

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 19]

Parameters MAY follow the type/subtype in the form of attribute/value pairs (as defined in section 3.6).

The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-

sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used

between the type and subtype, nor between an attribute and its value. The presence or absence of a parameter might

be significant to the processing of a media-type, depending on its definition within the media type registry.

Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP

applications, implementations SHOULD only use media type parameters when they are required by that type/subtype

definition.

Media-type values are registered with the Internet Assigned Number Authority (IANA [19]). The media type

registration process is outlined in RFC 1590 [17]. Use of non-registered media types is discouraged.

3.7.1 Canonicalization and Text Defaults

Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages MUST be

represented in the appropriate canonical form prior to its transmission except for “text” types, as defined in the next

paragraph.

When in canonical form, media subtypes of the “text” type use CRLF as the text line break. HTTP relaxes this

requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is

done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being

representative of a line break in text media received via HTTP. In addition, if the text is represented in a character

set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets,

HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR

and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR

or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and

multipart boundaries).

If an entity-body is encoded with a content-coding, the underlying data MUST be in a form defined above prior to

being encoded.

The “charset” parameter is used with some media types to define the character set (section 3.4) of the data. When no

explicit charset parameter is provided by the sender, media subtypes of the “text” type are defined to have a default

charset value of “ISO-8859-1” when received via HTTP. Data in character sets other than “ISO-8859-1” or its

subsets MUST be labeled with an appropriate charset value. See section 3.4.1 for compatibility problems.

3.7.2 Multipart Types

MIME provides for a number of “multipart” types -- encapsulations of one or more entities within a single message-

body. All multipart types share a common syntax, as defined in section 5.1.1 of RFC 2046 [40], and MUST include a

boundary parameter as part of the media type value. The message body is itself a protocol element and MUST

therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any

multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original

multipart contains an epilogue). These restrictions exist in order to preserve the self-delimiting nature of a multipart

message-body, wherein the “end” of the message-body is indicated by the ending multipart boundary.

In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The

one exception is the “multipart/byteranges” type (appendix 19.2) when it appears in a 206 (Partial Content) response,

which will be interpreted by some HTTP caching mechanisms as described in sections 13.5.4 and 14.16. In all other

cases, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt

of a multipart type. The MIME header fields within each body-part of a multipart message-body do not have any

significance to HTTP beyond that defined by their MIME semantics.

In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon

receipt of a multipart type. If an application receives an unrecognized multipart subtype, the application MUST treat

it as being equivalent to “multipart/mixed”.

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 20]

Note: The “multipart/form-data” type has been specifically defined for carrying form data suitable for

processing via the POST request method, as described in RFC 1867 [15].

3.8 Product Tokens

Product tokens are used to allow communicating applications to identify themselves by software name and version.

Most fields using product tokens also allow sub-products which form a significant part of the application to be listed,

separated by white space. By convention, the products are listed in order of their significance for identifying the

application.

product = token ["/" product-version]

product-version = token

Examples:

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

Server: Apache/0.8.4

Product tokens SHOULD be short and to the point. They MUST NOT be used for advertising or other non-essential

information. Although any token character MAY appear in a product-version, this token SHOULD only be

used for a version identifier (i.e., successive versions of the same product SHOULD only differ in the product-

version portion of the product value).

3.9 Quality Values

HTTP content negotiation (section 12) uses short “floating point” numbers to indicate the relative importance

(“weight”) of various negotiable parameters. A weight is normalized to a real number in the range 0 through 1,

where 0 is the minimum and 1 the maximum value. If a parameter has a quality value of 0, then content with this

parameter is ‘not acceptable’ for the client. HTTP/1.1 applications MUST NOT generate more than three digits after

the decimal point. User configuration of these values SHOULD also be limited in this fashion.

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

| ( "1" [ "." 0*3("0") ] )

“Quality values” is a misnomer, since these values merely represent relative degradation in desired quality.

3.10 Language Tags

A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for

communication of information to other human beings. Computer languages are explicitly excluded. HTTP uses

language tags within the Accept-Language and Content-Language fields.

The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 [1]. In summary, a language

tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:

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

primary-tag = 1*8ALPHA

subtag = 1*8ALPHA

White space is not allowed within the tag and all tags are case-insensitive. The name space of language tags is

administered by the IANA. Example tags include:

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

where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-

3166 country code. (The last three tags above are not registered tags; all but the last are examples of tags which

could be registered in future.)

3.11 Entity Tags

Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags

in the ETag (section 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and If-Range

剩余113页未读，继续阅读

luozhb529

粉丝: 2
资源: 18

HTTP/1.1协议RFC标准详解：互联网应用基石

HTTP1.1协议中文版-RFC2616

http1.1协议rfc2616中文版

中文HTTP1.1协议-RFC2616

HTTP1.1协议RFC2616中文版

HTTP1.1协议中文版RFC2616

HTTP 1.1标准RFC2616，中文版和英文版

http1.3.rar_http rfc_http1.1_rfc http

HTTP1.0&HTTP1.1（rfc2616）

HTTP1.1协议RFC中文全版本详解：功能增强与分层架构

HTTP/1.1协议RFC2616中文版详解与应用

最新资源