HTTP/1.1协议详解 - RFC2616标准文档

需积分: 9 154 浏览量更新于2024-07-31 收藏 702KB PDF 举报

"HTTP协议_RFC2616是互联网标准草案，定义了HTTP/1.1版本的协议规范，由R.Fielding等人编写，旨在替代RFC2068。这份文档详细阐述了HTTP协议用于互联网社区的标准轨道协议，并鼓励讨论和提出改进意见。HTTP是一种应用于分布式、协作式、超媒体信息系统的基础协议，不仅限于超文本传输，还可通过扩展其请求方法、错误代码和头部应用于域名服务器和分布式对象管理系统等场景。" RFC2616文档详细定义了HTTP/1.1协议的各个方面，包括以下几个关键知识点： 1. **HTTP方法**：HTTP协议定义了一系列请求方法，如GET（获取资源）、POST（提交数据）、PUT（替换资源）、DELETE（删除资源）等，这些方法用于客户端向服务器发送不同类型的请求。 2. **状态码**：HTTP响应中包含一个三位数的状态码，例如200表示成功，404表示未找到，500表示服务器内部错误等。状态码帮助客户端理解服务器处理请求的结果。 3. **首部字段**：HTTP请求和响应都包含了多个首部字段，如User-Agent（标识客户端类型）、Accept（指定客户端接受的媒体类型）、Content-Type（指定消息体的媒体类型）等，这些字段提供了额外的信息和控制选项。 4. **请求行与响应行**：每个HTTP消息都以一行开始，分别称为请求行和响应行，它们包含了请求方法、请求URI（统一资源标识符）和协议版本，或状态码和协议版本。 5. **实体主体**：请求或响应可能包含实体主体，用于传输数据，如POST请求中的表单数据，或者GET请求返回的HTML页面。 6. **缓存机制**：HTTP/1.1支持缓存机制，通过Cache-Control和ETag等首部字段控制资源的缓存和验证，以提高性能和减少网络流量。 7. **连接管理**：HTTP/1.1引入了持久连接，通过Keep-Alive首部允许在一个TCP连接上发送多个请求和响应，减少了建立新连接的开销。 8. **内容编码与压缩**：HTTP允许对实体主体进行编码（如gzip压缩），以减小传输数据的大小，提高传输效率。 9. **分块传输编码**：当实体主体的长度未知时，可以使用分块传输编码，将大实体分解成一系列较小的数据块发送。 10. **国际化和多部分消息**：HTTP/1.1支持Unicode字符集，同时通过MIME的多部分消息格式，允许在一个HTTP消息中传输多种类型的资源。这些知识点构成了HTTP/1.1协议的核心要素，理解并掌握它们对于开发和调试网络应用至关重要。由于HTTP/1.1是互联网上的基础协议之一，对它的深入理解有助于优化网络性能，解决跨域问题，以及实现高效的数据传输。

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

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

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

(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

alone representing a line break when it is

done consistently for an entire entity-body. HTTP applications MUST accept

CRLF

, bare

, and bare

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

and

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

and

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

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

zk_sima

粉丝: 23
资源: 4

HTTP/1.1协议详解 - RFC2616标准文档

HTTP/1.1 协议规范 RFC2616

HTTP协议特点与RFC2616中文版解读

HTTP/1.1协议规范RFC2616：1999年修订与概述

RFC2616_HTTP.rar_RFC2616_http 协议

HTTP协议中英文_RFC2616&RFC1945

超文本传输协议HTTP/1.1_RFC2616

RFC2616_cn.rar_RFC2616_typing

HTTP_RFC_2616_规范

RFC7047 ovsdb管理协议_rfc7047_ovsdbprotocol_

RFC中文文档大全.zip_RFC中文文档_RFC开发文档_rfc 中文_rfc1155中文文档_rfc文档中文版

最新资源