HTTP/1.1协议详解 - RFC2616

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

"HTTP1.1协议RFC2616文档" HTTP1.1协议是互联网上广泛使用的应用层协议，其定义在RFC2616文档中，由互联网工程任务组（IETF）制定，旨在规范和改进互联网社区的标准协议。这个文档由R.Fielding等人编写，于1999年发布，取代了之前的HTTP/1.0规范（RFC2068）。HTTP1.1协议不仅用于超文本传输，还适用于分布式、协作的信息系统，如名字服务器和分布式对象管理系统。 HTTP1.1的关键特性包括： 1. **状态码和错误代码**：HTTP1.1引入了更多的状态码来更精确地表示服务器对请求的响应，例如200（成功）、404（未找到）和500（服务器内部错误）。这些状态码帮助开发者诊断和解决网络问题。 2. **持久连接**：HTTP1.1支持持久连接（Keep-Alive），允许客户端和服务器在完成一次事务后保持连接打开，避免了每次请求都需要建立新的TCP连接，从而提高了效率。 3. **管道机制**：在持久连接的基础上，HTTP1.1引入了请求管道，允许客户端在一个连接上发送多个请求，而无需等待服务器对每个请求的响应，这进一步优化了性能。 4. **首部字段（Headers）的扩展**：HTTP1.1增加了许多新的首部字段，如Cache-Control用于缓存控制，Content-Length用于指定实体内容的长度，以及Accept-Encoding用于处理内容编码等，这些首部字段增强了协议的灵活性和功能。 5. **分块传输编码**：HTTP1.1允许大文件或动态生成的内容通过分块进行传输，每个块都有自己的大小，使得服务器可以在数据完全生成之前就开始发送。 6. **Host首部**：HTTP1.1要求所有请求必须包含Host首部，以便服务器能够区分同一IP地址上的多个虚拟主机，这对于多站点托管至关重要。 7. **方法扩展**：除了基本的GET、POST方法外，HTTP1.1还定义了PUT、DELETE、OPTIONS和其他方法，允许实现更多复杂的交互操作。 8. **断点续传**：Range请求头允许客户端请求文件的一部分，这对于大文件下载和恢复中断的下载特别有用。 9. **内容协商**：HTTP1.1支持内容协商，允许服务器根据客户端的偏好（如语言、编码、版本等）提供最合适的响应内容。 10. **安全性增强**：虽然HTTP本身不提供安全保证，但HTTP1.1通过与其他安全协议（如SSL/TLS）结合使用，可以实现安全的HTTPS连接，保护数据传输的安全性。 HTTP1.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页未读，继续阅读

enjoyinwind

粉丝: 54
资源: 9

HTTP/1.1协议详解 - RFC2616

http1.1协议rfc2616中文版

HTTP1.1协议RFC2616中文版

中文HTTP1.1协议-RFC2616

HTTP1.0&HTTP1.1（rfc2616）

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

HTTP/1.1协议RFC2616详解：应用级通用标准

HTTP/1.1协议RFC2616中文版：互联网标准与应用详解

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

HTTP/1.1规范RFC 2616：互联网应用协议详解

HTTP/1.1 协议规范 RFC2616

最新资源