HTTP/1.1协议标准：Hypertext Transfer Protocol的应用与扩展

需积分: 0 163 浏览量更新于2024-07-17 收藏 590KB PDF 举报

HTTP/1.1协议详解 HTTP（Hypertext Transfer Protocol）是一种应用层协议，用于分布式、协作的超媒体信息系统。它是一个通用的、无状态的协议，可以用于许多超越超文本的任务，如名称服务器和分布式对象管理系统，通过扩展其请求方法、错误代码和头信息。 **HTTP/1.1协议的特点** 1. **应用层协议**：HTTP是一个应用层协议，位于OSI七层模型的第七层，负责处理应用程序之间的通信。 2. **分布式、协作的超媒体信息系统**：HTTP支持分布式、协作的超媒体信息系统，可以实现多种类型的信息共享和交换。 3. **通用的、无状态的协议**：HTTP是一个通用的、无状态的协议，不保存任何会话信息，所有的请求和响应都是独立的。 4. **可扩展性**：HTTP协议可以通过扩展请求方法、错误代码和头信息来实现新的功能和应用。 **HTTP/1.1协议的组成部分** 1. **请求方法**：HTTP/1.1协议定义了多种请求方法，如GET、POST、HEAD、PUT、DELETE等，每种方法都有其特定的作用和应用场景。 2. **状态代码**：HTTP/1.1协议定义了一系列状态代码，用于表示服务器对客户端请求的响应结果，如200 OK、404 Not Found、500 Internal Server Error等。 3. **头信息**：HTTP/1.1协议定义了一系列头信息，用于传输附加信息，如Content-Type、Content-Length、Set-Cookie等。 **HTTP/1.1协议的应用** 1. **Web服务**：HTTP/1.1协议是Web服务的基础协议，用于实现Web服务器和客户端之间的通信。 2. **名称服务器**：HTTP/1.1协议可以用于名称服务器的实现，用于提供域名解析和IP地址解析服务。 3. **分布式对象管理系统**：HTTP/1.1协议可以用于分布式对象管理系统的实现，用于提供对象存储和管理服务。 **RFC2616规范** RFC2616是HTTP/1.1协议的规范文档，由Internet Engineering Task Force（IETF）发布，提供了HTTP/1.1协议的详细定义和实现规范。 **HTTP/1.1协议的优点** 1. **灵活性**：HTTP/1.1协议非常灵活，可以用于各种应用场景和系统环境。 2. **可扩展性**：HTTP/1.1协议可以通过扩展请求方法、错误代码和头信息来实现新的功能和应用。 3. **普及性**：HTTP/1.1协议是互联网上最广泛使用的协议之一，具有很高的普及性和兼容性。

RFC 2616 HTTP/1.1 June, 1999

Fielding, et al Standards Track [Page 15]

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet

comparison of the entire URIs, with these exceptions:

• A port that is empty or not given is equivalent to the default port for that URI-reference;

• Comparisons of host names MUST be case-insensitive;

• Comparisons of scheme names MUST be case-insensitive;

• An empty abs_path is equivalent to an abs_path of “/”.

Characters other than those in the “reserved” and “unsafe” sets (see RFC 2396 [42]) are equivalent to their “"%"

HEX HEX” encoding.

For example, the following three URIs are equivalent:

http://abc.com:80/~smith/home.html

http://ABC.com/%7Esmith/home.html

http://ABC.com:/%7esmith/home.html

3.3

Date/Time Formats

3.3.1 Full Date

HTTP applications have historically allowed three different formats for the representation of date/time stamps:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036

Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123

[8] (an update to RFC 822 [9]). The second format is in common use, but is based on the obsolete RFC 850 [12] date

format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value MUST accept all three

formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing

HTTP-date values in header fields. See section 19.3 for further information.

Note: Recipients of date values are encouraged to be robust in accepting date values that may have been

sent by non-HTTP applications, as is sometimes the case when retrieving or posting messages via

proxies/gateways to SMTP or NNTP.

All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the

purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two

formats by the inclusion of “GMT” as the three-letter abbreviation for time zone, and MUST be assumed when

reading the asctime format. HTTP-date is case sensitive and MUST NOT include additional LWS beyond that

specifically included as SP in the grammar.

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

; day month year (e.g., 02 Jun 1982)

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

; day-month-year (e.g., 02-Jun-82)

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

; month day (e.g., Jun 2)

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

; 00:00:00 - 23:59:59

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"

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”.

剩余114页未读，继续阅读

szengtal

粉丝: 41
资源: 4

HTTP/1.1协议标准：Hypertext Transfer Protocol的应用与扩展

rfc2327_SDP.pdf

rfc5506_RTCP.pdf

RFC2616_cn.rar_RFC2616_typing

RFC2616_HTTP.rar_RFC2616_http 协议

RFC1034_译文.pdf

rfc7252_COAP.pdf

rfc1034_en.pdf

rfc3489_STUN.pdf

hls直播协议_rfc8216_hls.pdf

RFC3501.rar_RFC3501_rfc 3501_rfc35_rfc3501 pdf_rfc3501.pdf

最新资源