HTTP/1.1 协议规范 RFC 2616 英文版详解

4星 · 超过85%的资源需积分: 0 38 浏览量更新于2024-07-27 收藏 538KB PDF 举报

"RFC 2616是HTTP 1.1协议的官方定义文档，由互联网工程任务组（IETF）发布，旨在规定互联网标准协议，并邀请社区进行讨论和改进建议。该文档由R. Fielding等人编写，于1999年6月发布。HTTP（超文本传输协议）是一种应用于分布式、协作式、超媒体信息系统的应用层协议，不仅限于处理超文本，还可通过扩展其请求方法、错误代码和头部来适应如域名系统服务器和分布式对象管理系统等用途。" 本文档RFC 2616详述了HTTP 1.1的主要特点和工作原理，其中包括以下几个关键知识点： 1. **状态码和原因短语**：HTTP协议通过状态码来表示请求的结果，如200表示成功，404表示未找到，500表示服务器内部错误等。原因短语是对状态码的可读性解释。 2. **请求方法**：HTTP 1.1支持多种请求方法，如GET用于获取资源，POST用于提交数据，PUT用于替换或创建资源，DELETE用于删除资源，HEAD用于仅获取响应头等。 3. **首部字段**：HTTP通信中包含了各种首部字段，如Accept用于指定客户端接受的媒体类型，Content-Type定义请求体或响应体的数据类型，Cookie和Set-Cookie用于管理会话。 4. **连接管理**：HTTP 1.1引入了持久连接（Keep-Alive），允许在单一TCP连接上处理多个请求，提高了效率并减少了延迟。 5. **缓存机制**：HTTP协议支持缓存响应，通过Cache-Control、Expires等首部字段控制缓存策略，减少网络传输，提高响应速度。 6. **分块传输编码**：对于大文件，HTTP 1.1允许使用分块传输编码，使得服务器可以逐步发送数据，客户端也可以逐步接收，改善了大文件传输的效率。 7. **内容编码与协商**：客户端和服务器可以通过Accept-Encoding和Content-Encoding首部协商数据的压缩方式，如gzip或deflate。 8. **URL和请求URI**：统一资源标识符（URI）是资源的全局唯一标识，而请求URI则指示客户端希望获取的特定资源。 9. **错误处理**：HTTP协议定义了一套错误代码，如401未授权，403禁止访问，404找不到资源等，用于指示客户端错误或服务器无法满足请求。 10. **版本标识**：HTTP 1.1协议引入了版本标识，允许在未来兼容新的协议版本。 HTTP 1.1是互联网上最广泛使用的协议之一，它的设计和规范对于理解网络通信、开发Web应用以及优化性能都至关重要。虽然随着时间的推移，HTTP 1.1已经被HTTP 2和HTTP/3取代，但许多基本概念和机制仍然沿用至今。

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页未读，继续阅读

johnny124

粉丝: 0
资源: 2

HTTP/1.1 协议规范 RFC 2616 英文版详解

3个HTTP协议书打包HTTP Developer's Handbook，HTTP--The Definitive Guide，RFC2616 HTTP1.1 PDF

RFC 2616 HTTP 1.1 超文本传输协议(中文版有目录) pdf

HTTP1.1英文版+RFC2616中文版等资料汇总.zip

ＲＦＣ２６１６(HTTP1.1)协议文档

rfc2616/HTTP/1.1中文版

http1.3.rar_http rfc_http1.1_rfc http

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

http-status-codes:枚举HTTP状态代码的常量。 支持RFC1945（HTTP1.0，RFC2616（HTTP1.1）和RFC2518（WebDAV）中定义的所有状态代码

HTTP1.1协议中文版RFC2616

http1.1协议rfc2616中文版

最新资源

http-status-codes:枚举HTTP状态代码的常量。支持RFC1945（HTTP1.0，RFC2616（HTTP1.1）和RFC2518（WebDAV）中定义的所有状态代码