HTTP/1.1协议详解：IETF RFC7230-7235

需积分: 10 41 浏览量更新于2024-07-21 收藏 490KB PDF 举报

"HTTP/1.1协议2014年最新版，由RFC7230至7235替代1999年的RFC2616，包含HTTP消息语法和路由的详细定义，以及相关安全考虑。" HTTP/1.1协议是互联网上广泛使用的应用层协议，用于在分布式、协作式的超文本信息系统中传输数据。这个协议的核心特性是无状态性，即每个请求都被独立处理，不依赖于之前的交互历史。HTTP/1.1是HTTP的最新版本，其规范由一系列的RFC（Request for Comments）文档组成，其中RFC7230至7235取代了1999年的RFC2616，对HTTP进行了更新和完善。 RFC7230主要关注HTTP的消息结构和路由，它首先概述了HTTP的架构及其相关的术语。HTTP架构基于客户端-服务器模型，客户端发起请求，服务器响应。请求和响应都由起始行、头部字段、空行和可选的实体主体组成。起始行包含了方法（如GET、POST等）、URL和协议版本信息。头部字段提供了关于请求或响应的元信息，如Accept（接受的媒体类型）、Host（指定服务器的主机名和端口号）等。 HTTP/1.1引入了持久连接（Persistent Connections）的概念，以减少因每次请求都要建立新的TCP连接带来的开销。这通过"Connection"头字段中的"Keep-Alive"选项来实现。此外，还定义了“http”和“https”两种URI（Uniform Resource Identifier）方案，前者用于明文传输，后者用于加密通信，基于SSL/TLS协议。在消息解析方面，RFC7230规定了如何正确解析和生成HTTP消息，包括分隔符的使用、编码规则、字符集处理等。例如，URL必须进行percent-encoded（%编码）以确保它们能在HTTP报文中安全传输。安全性是HTTP/1.1设计时的重要考量。协议中讨论了各种潜在的安全问题，如中间人攻击、跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。为了增强安全性，HTTP/1.1支持了如认证机制（通过Authorization和WWW-Authenticate头字段）、内容安全策略（Content-Security-Policy）等特性。 HTTP/1.1的更新还包括对WebSocket协议的支持（通过Upgrade头字段），WebSocket提供了一种全双工、低延迟的通信方式，常用于实时应用。此外，还更新了代理服务器的行为，如通过Proxy-Authenticate和Proxy-Authorization头字段进行代理认证。 HTTP/1.1协议2014年的新版不仅定义了HTTP消息的基本结构和路由，还涵盖了与安全性、效率和扩展性相关的多个方面，这些规定对于理解和实现HTTP/1.1服务器和客户端至关重要。

RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

message with a higher minor version, when sent to a recipient that

has not yet indicated support for that higher version, is

sufficiently backwards-compatible to be safely processed by any

implementation of the same major version.

2.7. Uniform Resource Identifiers

Uniform Resource Identifiers (URIs) [RFC3986] are used throughout

HTTP as the means for identifying resources (Section 2 of [RFC7231]).

URI references are used to target requests, indicate redirects, and

define relationships.

The definitions of "URI-reference", "absolute-URI", "relative-part",

"scheme", "authority", "port", "host", "path-abempty", "segment",

"query", and "fragment" are adopted from the URI generic syntax. An

"absolute-path" rule is defined for protocol elements that can

contain a non-empty path component. (This rule differs slightly from

the path-abempty rule of RFC 3986, which allows for an empty path to

be used in references, and path-absolute rule, which does not allow

paths that begin with "//".) A "partial-URI" rule is defined for

protocol elements that can contain a relative URI but not a fragment

component.

URI-reference = <URI-reference, see [RFC3986], Section 4.1>

absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>

relative-part = <relative-part, see [RFC3986], Section 4.2>

scheme = <scheme, see [RFC3986], Section 3.1>

authority = <authority, see [RFC3986], Section 3.2>

uri-host = <host, see [RFC3986], Section 3.2.2>

port = <port, see [RFC3986], Section 3.2.3>

path-abempty = <path-abempty, see [RFC3986], Section 3.3>

segment = <segment, see [RFC3986], Section 3.3>

query = <query, see [RFC3986], Section 3.4>

fragment = <fragment, see [RFC3986], Section 3.5>

absolute-path = 1*( "/" segment )

partial-URI = relative-part [ "?" query ]

Each protocol element in HTTP that allows a URI reference will

indicate in its ABNF production whether the element allows any form

of reference (URI-reference), only a URI in absolute form

(absolute-URI), only the path and optional query components, or some

combination of the above. Unless otherwise indicated, URI references

are parsed relative to the effective request URI (Section 5.5).

Fielding & Reschke Standards Track [Page 16]

RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

2.7.1. http URI Scheme

The "http" URI scheme is hereby defined for the purpose of minting

identifiers according to their association with the hierarchical

namespace governed by a potential HTTP origin server listening for

TCP ([RFC0793]) connections on a given port.

http-URI = "http:" "//" authority path-abempty [ "?" query ]

[ "#" fragment ]

The origin server for an "http" URI is identified by the authority

component, which includes a host identifier and optional TCP port

([RFC3986], Section 3.2.2). The hierarchical path component and

optional query component serve as an identifier for a potential

target resource within that origin server’s name space. The optional

fragment component allows for indirect identification of a secondary

resource, independent of the URI scheme, as defined in Section 3.5 of

[RFC3986].

A sender MUST NOT generate an "http" URI with an empty host

identifier. A recipient that processes such a URI reference MUST

reject it as invalid.

If the host identifier is provided as an IP address, the origin

server is the listener (if any) on the indicated TCP port at that IP

address. If host is a registered name, the registered name is an

indirect identifier for use with a name resolution service, such as

DNS, to find an address for that origin server. If the port

subcomponent is empty or not given, TCP port 80 (the reserved port

for WWW services) is the default.

Note that the presence of a URI with a given authority component does

not imply that there is always an HTTP server listening for

connections on that host and port. Anyone can mint a URI. What the

authority component determines is who has the right to respond

authoritatively to requests that target the identified resource. The

delegated nature of registered names and IP addresses creates a

federated namespace, based on control over the indicated host and

port, whether or not an HTTP server is present. See Section 9.1 for

security considerations related to establishing authority.

When an "http" URI is used within a context that calls for access to

the indicated resource, a client MAY attempt access by resolving the

host to an IP address, establishing a TCP connection to that address

on the indicated port, and sending an HTTP request message

(Section 3) containing the URI’s identifying data (Section 5) to the

server. If the server responds to that request with a non-interim

Fielding & Reschke Standards Track [Page 17]

RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

HTTP response message, as described in Section 6 of [RFC7231], then

that response is considered an authoritative answer to the client’s

request.

Although HTTP is independent of the transport protocol, the "http"

scheme is specific to TCP-based services because the name delegation

process depends on TCP for establishing authority. An HTTP service

based on some other underlying connection protocol would presumably

be identified using a different URI scheme, just as the "https"

scheme (below) is used for resources that require an end-to-end

secured connection. Other protocols might also be used to provide

access to "http" identified resources -- it is only the authoritative

interface that is specific to TCP.

The URI generic syntax for authority also includes a deprecated

userinfo subcomponent ([RFC3986], Section 3.2.1) for including user

authentication information in the URI. Some implementations make use

of the userinfo component for internal configuration of

authentication information, such as within command invocation

options, configuration files, or bookmark lists, even though such

usage might expose a user identifier or password. A sender MUST NOT

generate the userinfo subcomponent (and its "@" delimiter) when an

"http" URI reference is generated within a message as a request

target or header field value. Before making use of an "http" URI

reference received from an untrusted source, a recipient SHOULD parse

for userinfo and treat its presence as an error; it is likely being

used to obscure the authority for the sake of phishing attacks.

2.7.2. https URI Scheme

The "https" URI scheme is hereby defined for the purpose of minting

identifiers according to their association with the hierarchical

namespace governed by a potential HTTP origin server listening to a

given TCP port for TLS-secured connections ([RFC5246]).

All of the requirements listed above for the "http" scheme are also

requirements for the "https" scheme, except that TCP port 443 is the

default if the port subcomponent is empty or not given, and the user

agent MUST ensure that its connection to the origin server is secured

through the use of strong encryption, end-to-end, prior to sending

the first HTTP request.

https-URI = "https:" "//" authority path-abempty [ "?" query ]

[ "#" fragment ]

Note that the "https" URI scheme depends on both TLS and TCP for

establishing authority. Resources made available via the "https"

scheme have no shared identity with the "http" scheme even if their

Fielding & Reschke Standards Track [Page 18]

RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

resource identifiers indicate the same authority (the same host

listening to the same TCP port). They are distinct namespaces and

are considered to be distinct origin servers. However, an extension

to HTTP that is defined to apply to entire host domains, such as the

Cookie protocol [RFC6265], can allow information set by one service

to impact communication with other services within a matching group

of host domains.

The process for authoritative access to an "https" identified

resource is defined in [RFC2818].

2.7.3. http and https URI Normalization and Comparison

Since the "http" and "https" schemes conform to the URI generic

syntax, such URIs are normalized and compared according to the

algorithm defined in Section 6 of [RFC3986], using the defaults

described above for each scheme.

If the port is equal to the default port for a scheme, the normal

form is to omit the port subcomponent. When not being used in

absolute form as the request target of an OPTIONS request, an empty

path component is equivalent to an absolute path of "/", so the

normal form is to provide a path of "/" instead. The scheme and host

are case-insensitive and normally provided in lowercase; all other

components are compared in a case-sensitive manner. Characters other

than those in the "reserved" set are equivalent to their

percent-encoded octets: the normal form is to not encode them (see

Sections 2.1 and 2.2 of [RFC3986]).

For example, the following three URIs are equivalent:

http://example.com:80/˜smith/home.html

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

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

3. Message Format

All HTTP/1.1 messages consist of a start-line followed by a sequence

of octets in a format similar to the Internet Message Format

[RFC5322]: zero or more header fields (collectively referred to as

the "headers" or the "header section"), an empty line indicating the

end of the header section, and an optional message body.

HTTP-message = start-line

*( header-field CRLF )

CRLF

[ message-body ]

Fielding & Reschke Standards Track [Page 19]

RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

The normal procedure for parsing an HTTP message is to read the

start-line into a structure, read each header field into a hash table

by field name until the empty line, and then use the parsed data to

determine if a message body is expected. If a message body has been

indicated, then it is read as a stream until an amount of octets

equal to the message body length is read or the connection is closed.

A recipient MUST parse an HTTP message as a sequence of octets in an

encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP

message as a stream of Unicode characters, without regard for the

specific encoding, creates security vulnerabilities due to the

varying ways that string processing libraries handle invalid

multibyte character sequences that contain the octet LF (%x0A).

String-based parsers can only be safely used within protocol elements

after the element has been extracted from the message, such as within

a header field-value after message parsing has delineated the

individual fields.

An HTTP message can be parsed as a stream for incremental processing

or forwarding downstream. However, recipients cannot rely on

incremental delivery of partial messages, since some implementations

will buffer or delay message forwarding for the sake of network

efficiency, security checks, or payload transformations.

A sender MUST NOT send whitespace between the start-line and the

first header field. A recipient that receives whitespace between the

start-line and the first header field MUST either reject the message

as invalid or consume each whitespace-preceded line without further

processing of it (i.e., ignore the entire line, along with any

subsequent lines preceded by whitespace, until a properly formed

header field is received or the header section is terminated).

The presence of such whitespace in a request might be an attempt to

trick a server into ignoring that field or processing the line after

it as a new request, either of which might result in a security

vulnerability if other implementations within the request chain

interpret the same message differently. Likewise, the presence of

such whitespace in a response might be ignored by some clients or

cause others to cease parsing.

3.1. Start Line

An HTTP message can be either a request from client to server or a

response from server to client. Syntactically, the two types of

message differ only in the start-line, which is either a request-line

(for requests) or a status-line (for responses), and in the algorithm

for determining the length of the message body (Section 3.3).

Fielding & Reschke Standards Track [Page 20]

剩余304页未读，继续阅读

lispythonic

粉丝: 4
资源: 7

HTTP/1.1协议详解：IETF RFC7230-7235

龍宰web协议源码2014年7月最新版

HTTP协议(RFC2616)中文版

2014年最新 H3CSE GB0-380 V11.02.500道题。

FWR310V4.0固件 FWR310v4_0.9.0_1.1_up(141014)_2014-10-14_16.33.18

NFC Activity Technical Specification 1.1.pdf

IPMI v2.0 from intel r1.1

SGP.01(eSIM architecture)-v1.1

tomcat最新版

tomcat包含7/8/9各个版本

最新版本(OpenSSL1.0.1e)libssl.so, libcrypto.so for Android

最新资源