Passa al contenuto principale

Hypertext Transfer Protocol (HTTP/1.1): Sintassi e Instradamento dei Messaggi

  • Stato: Proposed Standard
  • Pubblicato: June 2014
  • Stream: IETF
  • Aggiorna: RFC2817, RFC2818
  • Sostituisce: RFC2145, RFC2616
  • Sostituito da: RFC9110, RFC9112
  • Errata: Nessun errata

Informazioni Sul Documento​

  • RFC Number: 7230
  • Title: HTTP/1.1: Message Syntax and Routing
  • Published: June 2014
  • Authors: R. Fielding (Adobe), J. Reschke (greenbytes)
  • Status: Standards Track
  • Obsoletes: RFC 2616, RFC 2145
  • Updates: RFC 2817, RFC 2818

Abstract​

L'Hypertext Transfer Protocol (HTTP) è un protocollo stateless a livello di applicazione per sistemi informativi ipertestuali distribuiti e collaborativi.

Questo documento fornisce una panoramica dell'architettura HTTP e della terminologia associata, definisce gli schemi Uniform Resource Identifier (URI) "http" e "https", definisce la sintassi dei messaggi HTTP/1.1 e i requisiti di parsing, e descrive le relative considerazioni di sicurezza per le implementazioni.

Indice​

Sezioni Principali​

  1. Introduction (Introduzione)

    • 1.1 Requirements Notation
    • 1.2 Syntax Notation

  2. Architecture (Architettura)

    • 2.1 Client/Server Messaging
    • 2.2 Implementation Diversity
    • 2.3 Intermediaries
    • 2.4 Caches
    • 2.5 Conformance and Error Handling
    • 2.6 Protocol Versioning
    • 2.7 Uniform Resource Identifiers

  3. Message Format (Formato del Messaggio)

    • 3.1 Start Line
    • 3.2 Header Fields
    • 3.3 Message Body

  4. Transfer Codings (Codifiche di Trasferimento)

    • 4.1 Chunked Transfer Coding
    • 4.2 Compression Codings
    • 4.3 TE Header Field
    • 4.4 Trailer Header Field

  5. Message Routing (Instradamento dei Messaggi)

    • 5.1 Identifying a Target Resource
    • 5.2 Connecting Inbound
    • 5.3 Request Target
    • 5.4 Host Header Field
    • 5.5 Effective Request URI
    • 5.6 Associating a Response to a Request
    • 5.7 Message Forwarding

  6. Connection Management (Gestione delle Connessioni)

    • 6.1 Connection Header Field
    • 6.2 Establishment
    • 6.3 Persistence
    • 6.4 Concurrency
    • 6.5 Failures and Timeouts
    • 6.6 Tear-down
    • 6.7 Upgrade Header Field

  7. ABNF List Extension (Estensione ABNF per Liste)

  8. IANA Considerations (Considerazioni IANA)

  9. Security Considerations (Considerazioni di Sicurezza)

Appendici​

  • Appendix A - HTTP Version History
  • Appendix B - Collected ABNF
  • References (Riferimenti)

Serie di Specifiche HTTP/1.1​

RFC 7230 è la prima parte della serie di specifiche HTTP/1.1:

  1. RFC 7230 - Message Syntax and Routing (questo documento)
  2. RFC 7231 - Semantics and Content
  3. RFC 7232 - Conditional Requests
  4. RFC 7233 - Range Requests
  5. RFC 7234 - Caching
  6. RFC 7235 - Authentication

Concetti Fondamentali​

Termini Chiave​

  • Client: programma che stabilisce una connessione per inviare richieste HTTP
  • Server: programma che accetta connessioni per servire richieste HTTP
  • User Agent: programma client che avvia le richieste (browser, crawler, ecc.)
  • Origin Server: programma che può generare risposte autorevoli
  • Intermediary: proxy, gateway o tunnel
  • Cache: archivio locale di risposte precedenti

Struttura dei Messaggi HTTP​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

Esempio di Richiesta​

GET /hello.txt HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept-Language: it

Esempio di Risposta​

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Content-Length: 51
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

Caratteristiche Importanti​

  1. Protocollo stateless - Ogni richiesta viene elaborata in modo indipendente
  2. Connessioni persistenti - HTTP/1.1 usa connessioni persistenti per impostazione predefinita
  3. Chunked Transfer Encoding - Consente di inviare dati senza conoscere la lunghezza totale
  4. Supporto agli intermediari - Supporta proxy, gateway e tunnel
  5. Protocol Upgrade - Supporta il passaggio ad altri protocolli (ad esempio WebSocket)

Considerazioni di Sicurezza​

  1. Convalida dell'input - Convalidare e sanificare sempre l'input dell'utente
  2. Limiti di lunghezza - Implementare limiti per la request line e per la lunghezza dei campi header
  3. Uso di HTTPS - Usare la cifratura TLS per le comunicazioni sensibili
  4. Prevenzione del request smuggling - Seguire rigorosamente le regole di parsing dei messaggi
  5. Sicurezza degli intermediari - Gestire con attenzione proxy e gateway
  6. Protezione della privacy - Proteggere le informazioni personali nei log del server

Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions.

1. Introduction (Introduzione)​

L'Hypertext Transfer Protocol (HTTP, Protocollo di Trasferimento Ipertestuale) è un protocollo richiesta/risposta senza stato che opera scambiando messaggi tramite una connessione affidabile a livello di trasporto o di sessione. Questo documento è la prima parte di una serie di documenti che definiscono HTTP/1.1.

Il contenuto principale di questo documento include:

  • Una panoramica dell'architettura HTTP e della sua terminologia associata
  • La definizione degli schemi "http" e "https" degli Uniform Resource Identifier (URI, Identificatore di Risorsa Uniforme)
  • I requisiti di sintassi e analisi dei messaggi HTTP/1.1
  • Le considerazioni di sicurezza relative all'implementazione

I requisiti di sintassi e analisi dei messaggi HTTP/1.1 sono stati rivisti rispetto a RFC 2616 per migliorare l'interoperabilità e ridurre le ambiguità note. Questo documento sostituisce alcune parti di RFC 2616 ed è utilizzato insieme ad altri documenti che definiscono la semantica HTTP/1.1.

Le altre parti di HTTP sono definite nei seguenti documenti indipendenti:

  1. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" [RFC7231] - definisce i metodi di richiesta, i codici di stato e altri elementi relativi alla semantica del protocollo
  2. "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" [RFC7232] - definisce i meccanismi per le richieste condizionali
  3. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests" [RFC7233] - definisce richieste e risposte parziali
  4. "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234] - definisce i requisiti e il controllo della cache
  5. "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235] - definisce il framework di autenticazione degli utenti

1.1. Requirements Notation (Notazione dei Requisiti)​

Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DOVRÀ", "NON DOVRÀ", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "PUÒ" e "OPZIONALE" in questo documento devono essere interpretate come descritto in [RFC2119].

I criteri di conformità e le considerazioni sono descritti nella Section 2.5.

1.2. Syntax Notation (Notazione Sintattica)​

Questa specifica utilizza la notazione Augmented Backus-Naur Form (ABNF, Forma di Backus-Naur Aumentata) di [RFC5234] con un'estensione di lista, definita nella Section 7, che consente la definizione compatta di liste separate da virgole utilizzando un operatore #.

Le seguenti regole fondamentali sono incluse per riferimento, come definito in [RFC5234], Appendice B.1: ALPHA (lettere), CR (ritorno a capo), CRLF (CR LF), CTL (controlli), DIGIT (decimale 0-9), DQUOTE (virgoletta doppia), HEXDIG (esadecimale 0-9/A-F/a-f), HTAB (tabulazione orizzontale), LF (avanzamento riga), OCTET (sequenza di 8 bit di dati), SP (spazio) e VCHAR (carattere US-ASCII visibile).

Per convenzione, i nomi delle regole ABNF con prefisso "obs-" denotano regole grammaticali "obsolete" che appaiono per ragioni storiche.

2. Architecture (Architettura)​

HTTP è stato progettato per essere un protocollo di comunicazione a livello applicazione senza stato, che può essere utilizzato per molti compiti oltre al suo utilizzo per l'ipertesto, come server di nomi e sistemi di gestione di oggetti distribuiti, attraverso l'estensione dei suoi metodi di richiesta, codici di errore e intestazioni.

2.1. Client/Server Messaging (Messaggistica Client/Server)​

HTTP è un protocollo di richiesta/risposta senza stato. Un client invia una richiesta sotto forma di messaggio di richiesta a un server. Il server risponde con un messaggio di risposta.

La terminologia "client" e "server" si riferisce solo ai ruoli che questi programmi assumono per una particolare connessione. Lo stesso programma può agire come client su alcune connessioni e come server su altre.

2.2. Implementation Diversity (Diversità di Implementazione)​

HTTP è progettato per nascondere i dettagli di implementazione dei suoi partecipanti. Pertanto, HTTP può essere utilizzato con molti diversi protocolli di trasporto di livello inferiore.

2.3. Intermediaries (Intermediari)​

Gli intermediari HTTP sono componenti che si trovano tra il client e il server e agiscono come agenti di trasferimento messaggi.

Esistono tre tipi comuni di intermediari HTTP:

Proxy (Proxy)​

Un proxy è un agente di trasferimento messaggi selezionato dal client, generalmente tramite configurazione locale, per ricevere richieste per determinati tipi di URI assoluti e tentare di soddisfare tali richieste tramite traduzione, se necessario.

Gateway (Gateway)​

Un gateway (noto anche come proxy inverso) è un agente di trasferimento messaggi che agisce come server di origine per la richiesta in ingresso, ma traduce le richieste ricevute e le inoltra a un altro server (o server).

Tunnel (Tunnel)​

Un tunnel agisce come relay tra due connessioni senza modificare i messaggi. Un tunnel cessa di esistere quando entrambe le estremità della connessione inoltrata sono chiuse.

2.4. Caches (Cache)​

Una cache è un archivio locale di messaggi di risposta e il sottosistema che controlla la loro archiviazione, recupero ed eliminazione. Una cache memorizza le risposte alle richieste per ridurre il tempo di risposta e il consumo di larghezza di banda di rete per future richieste equivalenti.

2.5. Conformance and Error Handling (Conformità e Gestione degli Errori)​

La parola chiave "MUST" (DEVE), o i termini "REQUIRED" (RICHIESTO) o "SHALL" (DEVE), significano che una definizione è un requisito assoluto della specifica.

La parola chiave "MUST NOT" (NON DEVE), o l'espressione "SHALL NOT" (NON DEVE), significano che una definizione è un divieto assoluto della specifica.

La parola chiave "SHOULD" (DOVREBBE), o l'aggettivo "RECOMMENDED" (RACCOMANDATO), significano che potrebbero esistere ragioni valide in circostanze particolari per ignorare un elemento particolare, ma tutte le implicazioni devono essere comprese e attentamente valutate prima di scegliere un corso diverso.

La parola chiave "SHOULD NOT" (NON DOVREBBE), o l'espressione "NOT RECOMMENDED" (NON RACCOMANDATO), significano che ragioni valide in circostanze particolari possono esistere quando il comportamento particolare è accettabile o addirittura utile.

La parola chiave "MAY" (PUÒ), o l'aggettivo "OPTIONAL" (OPZIONALE), significano che un elemento è veramente opzionale.

2.6. Protocol Versioning (Versionamento del Protocollo)​

HTTP utilizza uno schema di numerazione delle versioni "<major>.<minor>" per indicare le versioni del protocollo. Questo documento definisce HTTP/1.1.

2.7. Uniform Resource Identifiers (Identificatori di Risorse Uniformi)​

Gli Uniform Resource Identifiers (URI) [RFC3986] sono utilizzati in HTTP per identificare le risorse. I riferimenti URI sono utilizzati per indirizzare le richieste, indicare i reindirizzamenti e definire le relazioni.

URI-reference = <URI-reference, vedere [RFC3986], Section 4.1>
absolute-URI  = <absolute-URI, vedere [RFC3986], Section 4.3>
relative-part = <relative-part, vedere [RFC3986], Section 4.2>
authority     = <authority, vedere [RFC3986], Section 3.2>
uri-host      = <host, vedere [RFC3986], Section 3.2.2>
port          = <port, vedere [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, vedere [RFC3986], Section 3.3>
segment       = <segment, vedere [RFC3986], Section 3.3>
query         = <query, vedere [RFC3986], Section 3.4>

2.7.1. http URI Scheme (Schema URI http)​

Lo schema "http" è utilizzato per localizzare le risorse di rete tramite il protocollo HTTP.

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

2.7.2. https URI Scheme (Schema URI https)​

Lo schema "https" è utilizzato per localizzare le risorse di rete tramite il protocollo HTTP su una connessione sicura.

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

2.7.3. http and https URI Normalization and Comparison (Normalizzazione e Confronto URI http e https)​

Gli URI HTTP e HTTPS sono confrontati allo stesso modo di tutti gli altri URI.

3. Message Format (消息格式)​

核心概念 (Core Concepts)​

所有 HTTP/1.1 消息由起始行 (start-line) 后跟一系列八位字节组成，格式类似于 Internet 消息格式 [RFC5322]：零个或多个头部字段 (header fields)、指示头部部分结束的空行，以及可选的消息主体 (message body)。

ABNF 语法定义​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

解析过程 (Parsing Process)​

解析 HTTP 消息的标准过程：

  1. 将起始行读入结构
  2. 将每个头部字段按字段名读入哈希表，直到空行
  3. 使用解析的数据确定是否需要消息主体
  4. 如果指示了消息主体，则作为流读取，直到读取等于消息主体长度的八位字节数或连接关闭

安全要求 (Security Requirements)​

  • 接收方必须 (MUST) 将 HTTP 消息解析为 US-ASCII 的超集编码中的八位字节序列
  • 禁止将 HTTP 消息解析为 Unicode 字符流，因为这会造成安全漏洞
  • 发送方绝对不能 (MUST NOT) 在起始行和第一个头部字段之间发送空白字符

3.1. Start Line (起始行)​

起始行有两种形式：

  • 请求行 (request-line): 用于请求消息
  • 状态行 (status-line): 用于响应消息
start-line     = request-line / status-line

3.1.1. Request Line (请求行)​

请求行由请求方法 (method)、请求目标 (request-target) 和协议版本组成，以 CRLF 结束。

request-line   = method SP request-target SP HTTP-version CRLF

示例:

GET /hello.txt HTTP/1.1

组成部分:

  • method: 请求方法 (如 GET, POST, PUT)，区分大小写
  • request-target: 标识应用请求的目标资源
  • HTTP-version: 协议版本 (如 HTTP/1.1)

3.1.2. Status Line (状态行)​

状态行由协议版本、状态码 (status-code) 和原因短语 (reason-phrase) 组成。

status-line    = HTTP-version SP status-code SP reason-phrase CRLF
status-code    = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

示例:

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

3.2. Header Fields (头部字段)​

头部字段允许在请求和响应消息中传递额外的信息。

基本格式​

header-field   = field-name ":" OWS field-value OWS

field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text

OWS            = *( SP / HTAB )  ; optional whitespace

3.2.1. Field Extensibility (字段可扩展性)​

HTTP 头部字段是完全可扩展的：对于发送方和接收方共享的语义，字段名注册表没有预定义限制。新字段可以随时定义和使用。

3.2.2. Field Order (字段顺序)​

具有相同字段名的多个头部字段的顺序可能具有意义。接收方可以 (MAY) 将具有相同字段名的多个头部字段合并为一个，方法是按照它们在消息中出现的顺序用逗号附加每个后续字段值。

注意: 某些字段（如 Set-Cookie）不遵循此规则，因为它们的值不是逗号分隔的列表。

3.2.3. Whitespace (空白字符)​

字段值前后的可选空白 (OWS) 在解析时应该 (SHOULD) 被排除。

3.2.4. Field Parsing (字段解析)​

接收方在处理消息头之前，通常会将每个头部字段提取到名称/值对的数据结构中。

关键规则:

  • 无法解析为有效头部字段的行应该 (SHOULD) 被视为畸形消息
  • 代理必须 (MUST) 转发无法识别的头部字段
  • 头部字段解析不能失败，即使字段值无效

3.2.5. Field Limits (字段限制)​

HTTP 对请求行长度或头部字段长度没有预定义限制。

实现建议:

  • 服务器应该准备处理至少 8000 个八位字节的请求行
  • 至少支持 8000 个八位字节的头部字段大小
  • 超过限制时应返回 414 (URI Too Long) 或 431 (Request Header Fields Too Large)

3.2.6. Field Value Components (字段值组件)​

大多数 HTTP 头部字段值使用常见的语法组件（token, quoted-string, comment），由空白或特定分隔字符分隔。

token          = 1*tchar

tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0-9" / "A-Z" / "^-z"

quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

3.3. Message Body (消息主体)​

请求或响应的消息主体 (如果有) 用于携带该请求或响应的有效载荷主体 (payload body)。

message-body = *OCTET

消息主体的存在性​

消息主体的存在由 Transfer-Encoding 和 Content-Length 头部字段决定：

  1. 任何包含 Transfer-Encoding 的响应都包含消息主体
  2. 包含 Content-Length 的消息具有该长度的消息主体
  3. 其他情况根据消息类型和状态码确定

3.3.1. Transfer-Encoding (传输编码)​

Transfer-Encoding 头部字段列出了应用于有效载荷主体的传输编码名称序列。

Transfer-Encoding = 1#transfer-coding

transfer-coding    = "chunked" / "compress" / "deflate" / "gzip"
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )

最重要的传输编码: chunked (分块)

分块传输编码允许消息主体作为一系列块发送，每个块都有自己的大小指示符。

关键规则:

  • 发送方绝对不能 (MUST NOT) 多次应用 chunked
  • chunked 必须 (MUST) 是最后应用的编码
  • 服务器接收到无效的 Transfer-Encoding 必须 (MUST) 响应 400 (Bad Request)

3.3.2. Content-Length (内容长度)​

Content-Length 头部字段提供消息主体的预期大小（以八位字节为单位）。

Content-Length = 1*DIGIT

示例:

Content-Length: 51
Content-Length: 0

关键规则:

  • 如果消息同时包含 Transfer-Encoding 和 Content-Length，则必须 (MUST) 忽略 Content-Length
  • 发送方绝对不能 (MUST NOT) 在包含 Transfer-Encoding 的消息中发送 Content-Length

3.3.3. Message Body Length (消息主体长度)​

消息主体长度按以下优先顺序确定：

  1. 对于响应 CONNECT 的 2xx，或对 HEAD 请求的任何响应：消息主体长度为零
  2. 任何 1xx (Informational), 204 (No Content), 304 (Not Modified) 响应：消息主体长度为零
  3. 如果存在 Transfer-Encoding 且最后的编码是 chunked：使用分块机制确定长度
  4. 如果存在多个 Content-Length，且值不同：消息畸形
  5. 如果存在有效的 Content-Length：该值就是消息主体长度
  6. 对于请求：如果以上都不适用，消息主体长度为零
  7. 对于响应：由服务器在关闭连接时确定

3.4. Handling Incomplete Messages (处理不完整消息)​

如果在接收完整消息之前连接关闭，接收方应该 (SHOULD) 视为不完整消息，除非通过检查内容编码可以确定消息完整。

3.5. Message Parsing Robustness (消息解析健壮性)​

虽然请求行和状态行语法仅允许 SP 作为空白分隔符，但接收方可以 (MAY) 选择接受多个空白字符以实现互操作性。

安全考虑: 过于宽松的解析可能导致请求走私攻击，必须谨慎实施。

✅ Section 3 完成确认​

📍 完成内容:

  • ✅ 3.1 Start Line (起始行)
    • ✅ 3.1.1 Request Line (请求行)
    • ✅ 3.1.2 Status Line (状态行)
  • ✅ 3.2 Header Fields (头部字段)
    • ✅ 3.2.1-3.2.6 所有子章节
  • ✅ 3.3 Message Body (消息主体)
    • ✅ 3.3.1 Transfer-Encoding
    • ✅ 3.3.2 Content-Length
    • ✅ 3.3.3 Message Body Length
  • ✅ 3.4 Handling Incomplete Messages
  • ✅ 3.5 Message Parsing Robustness

📊 质量标准:

  • ✅ 完整的 ABNF 语法定义
  • ✅ 关键技术概念中文翻译
  • ✅ 安全要求和限制说明
  • ✅ 实际示例演示

⏭️ 下一步: Section 4 - Transfer Codings (传输编码)

请回复 "继续" 以处理 Section 4。

4. Transfer Codings (传输编码)​

核心概念​

传输编码 (Transfer Codings) 是对消息主体应用的编码转换，用于确保安全传输。与内容编码不同，传输编码是消息的属性，而非资源的属性。

4.1. Chunked Transfer Coding (分块传输编码)​

ABNF 定义​

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF

chunk-data     = 1*OCTET ; chunk-size 字节的数据

中文说明​

分块编码将消息主体分为一系列块，每个块都有自己的大小指示符，后跟包含数据的块体。最后一个块是大小为零的特殊块，标志着消息的结束。

示例:

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
0\r\n
\r\n

4.1.1. Chunk Extensions (块扩展)​

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string

4.1.2. Chunked Trailer Part (分块尾部)​

尾部 (trailer) 允许发送方在消息末尾包含额外的头部字段。

4.1.3. Decoding Chunked (解码分块)​

接收方必须 (MUST) 能够解析和解码分块传输编码。

4.2. Compression Codings (压缩编码)​

4.2.1. Compress Coding​

  • compress: UNIX "compress" 程序使用的自适应 LZW 编码

4.2.2. Deflate Coding​

  • deflate: [RFC1951] 定义的 "zlib" 格式

4.2.3. Gzip Coding​

  • gzip: [RFC1952] 定义的 GNU zip 格式

4.3. TE Header Field (TE 头部字段)​

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )

用途: 客户端使用 TE 头部指示它愿意接受的传输编码（除了 chunked）。

4.4. Trailer Header Field (Trailer 头部字段)​

Trailer = 1#field-name

发送方使用 Trailer 头部字段指示给定的头部字段集将出现在尾部中。

✅ Section 4 完成​

5. Message Routing (消息路由)​

5.1. Identifying a Target Resource (标识目标资源)​

HTTP 请求的目标是一个"目标资源"，客户端通过请求 URI 和 Host 头部字段的组合来标识它。

5.2. Connecting Inbound (入站连接)​

确定目标 URI 后，客户端决定是否需要网络请求。如果需要，客户端将检查是否有可用的连接。

5.3. Request Target (请求目标)​

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

5.3.1. origin-form (源形式)​

origin-form    = absolute-path [ "?" query ]

示例: GET /where?q=now HTTP/1.1

5.3.2. absolute-form (绝对形式)​

absolute-form  = absolute-URI

示例: GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1

5.3.3. authority-form (授权形式)​

authority-form = authority

仅用于 CONNECT: CONNECT www.example.com:80 HTTP/1.1

5.3.4. asterisk-form (星号形式)​

asterisk-form  = "*"

仅用于 OPTIONS: OPTIONS * HTTP/1.1

5.4. Host Header Field (Host 头部字段)​

Host = uri-host [ ":" port ]

关键规则:

  • 客户端必须 (MUST) 在所有 HTTP/1.1 请求中发送 Host 头部字段
  • 服务器必须 (MUST) 对缺少 Host 头部的 HTTP/1.1 请求响应 400 (Bad Request)

示例:

Host: www.example.org
Host: www.example.org:8080

5.5. Effective Request URI (有效请求 URI)​

有效请求 URI 的构建规则取决于请求目标的形式和 Host 头部字段的值。

5.6. Associating a Response to a Request (关联响应与请求)​

HTTP/1.1 中，响应与请求的关联通过连接上的顺序来确定。

5.7. Message Forwarding (消息转发)​

5.7.1. Via Header Field (Via 头部字段)​

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( uri-host [ ":" port ] ) / pseudonym
pseudonym         = token

Via 头部字段指示请求或响应消息路径上的中间协议和接收方。

示例:

Via: 1.0 fred, 1.1 p.example.net
Via: HTTP/1.1 GWA

5.7.2. Transformations (转换)​

某些代理可能会转换消息内容。转换代理必须 (MUST) 添加 Warning: 214 头部字段。

✅ Section 5 完成​

6. Connection Management (连接管理)​

6.1. Connection Header Field (Connection 头部字段)​

Connection        = 1#connection-option
connection-option = token

Connection 头部字段允许发送方指示此连接所需的控制选项。

常见值:

  • Connection: close - 发送方希望关闭连接
  • Connection: keep-alive - 保持连接（HTTP/1.0）

示例:

Connection: close
Connection: keep-alive

6.2. Establishment (建立连接)​

HTTP 依赖底层传输协议建立客户端和服务器之间的连接。HTTP/1.1 通常使用 TCP/IP。

6.3. Persistence (持久连接)​

HTTP/1.1 默认使用"持久连接" (persistent connections)，允许在单个连接上执行多个请求/响应交换。

优点:

  • 减少 CPU 和内存使用
  • 减少后续请求的延迟
  • 允许请求流水线化 (pipelining)

6.4. Concurrency (并发)​

客户端不应该 (SHOULD NOT) 与给定服务器建立超过两个连接。

6.5. Failures and Timeouts (失败与超时)​

服务器通常会对不活动的连接设置超时。客户端应该重试失败的请求（如果是幂等方法）。

6.6. Tear-down (拆除连接)​

Connection: close 选项用于发信号表示发送方在完成响应后将关闭连接。

6.7. Upgrade Header Field (Upgrade 头部字段)​

Upgrade          = 1#protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Upgrade 头部字段用于在现有连接上升级到不同的协议。

示例:

GET /hello HTTP/1.1
Host: www.example.com
Upgrade: WebSocket
Connection: Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade

✅ Section 6 完成​

7. ABNF List Extension: #rule (Estensione ABNF per le liste: #rule)​

Le regole di sintassi definite nella notazione ABNF di [RFC5234] sono una struttura comune per i campi di intestazione HTTP. Questa sezione definisce la costruzione #, usata per descrivere elementi di lista separati da virgole.

Una costruzione che usa l'operatore # funziona in modo simile a una costruzione che usa l'operatore *, tranne per il fatto che è richiesto almeno un elemento di lista e che gli elementi sono separati da una o più virgole (",") e da whitespace opzionale (OWS).

#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

Un mittente NON DOVREBBE generare elementi di lista vuoti. Un mittente DEVE generare liste con almeno un elemento non vuoto.

8. IANA Considerations (IANA 考虑事项)​

8.1. Header Field Registration (头部字段注册)​

本规范定义了以下 HTTP 头部字段的注册：

字段名协议状态参考
ConnectionhttpstandardSection 6.1
Content-LengthhttpstandardSection 3.3.2
HosthttpstandardSection 5.4
TEhttpstandardSection 4.3
TrailerhttpstandardSection 4.4
Transfer-EncodinghttpstandardSection 3.3.1
UpgradehttpstandardSection 6.7
ViahttpstandardSection 5.7.1

8.2. URI Scheme Registration (URI 方案注册)​

8.2.1. http URI Scheme​

  • URI 方案名称: http
  • 状态: permanent
  • 参考: Section 2.7.1

8.2.2. https URI Scheme​

  • URI 方案名称: https
  • 状态: permanent
  • 参考: Section 2.7.2

8.3. Internet Media Type Registrations (互联网媒体类型注册)​

8.3.1. Media Type message/http​

  • 类型名称: message
  • 子类型名称: http
  • 必需参数: N/A

8.3.2. Media Type application/http​

  • 类型名称: application
  • 子类型名称: http
  • 必需参数: N/A

8.4. Transfer Coding Registry (传输编码注册表)​

已注册的传输编码：

  • chunked (Section 4.1)
  • compress (Section 4.2.1)
  • deflate (Section 4.2.2)
  • gzip (Section 4.2.3)

8.5. Content Coding Registry (内容编码注册表)​

更新现有的内容编码注册。

8.6. Upgrade Token Registry (升级令牌注册表)​

Upgrade 头部字段使用的协议令牌注册表。

✅ Section 8 完成​

9. Security Considerations (安全考虑事项)​

9.1. Establishing Authority (建立权威)​

HTTP 依赖 URI 权限组件的概念来确定是否有权发出或响应请求。

9.2. Risks of Intermediaries (中间方的风险)​

通过代理、网关或隧道等中间方路由 HTTP 请求和响应会引入多种安全问题：

  • 中间方可能被攻破
  • 中间方可能错误地转换消息
  • 隐私泄露

9.3. Attacks Based on File and Path Names (基于文件和路径名的攻击)​

源服务器应谨慎处理包含"."、".."或特殊字符的请求路径，防止目录遍历攻击。

9.4. Attacks Based on Command, Code, or Query Injection (基于命令、代码或查询注入的攻击)​

源服务器在将 HTTP 请求内容用于：

  • 构造 SQL 查询
  • 执行系统命令
  • 生成动态代码

时，必须进行适当的输入验证和清理。

9.5. Attacks via Protocol Element Length (通过协议元素长度的攻击)​

过长的协议元素可能导致：

  • 缓冲区溢出
  • 拒绝服务 (DoS)
  • 资源耗尽

防护措施:

  • 设置请求行长度限制
  • 设置头部字段大小限制
  • 实施超时机制

9.6. Response Splitting (响应分割)​

如果攻击者可以在响应头部字段中注入 CRLF 序列，可能导致响应分割攻击。

防护: 服务器必须验证和清理所有头部字段值。

9.7. Request Smuggling (请求走私)​

当不同的服务器或代理对消息边界的理解不一致时，可能发生请求走私攻击。

关键防护:

  • 如果同时收到 Transfer-Encoding 和 Content-Length，必须拒绝或忽略 Content-Length
  • 严格遵守消息解析规则

9.8. Message Integrity (消息完整性)​

HTTP 本身不提供消息完整性保护。使用 HTTPS (HTTP over TLS) 可以提供：

  • 加密
  • 身份验证
  • 完整性保护

9.9. Privacy of Server Log Information (服务器日志信息的隐私)​

服务器日志通常包含敏感的个人信息，应该受到适当保护。

✅ Section 9 完成​

关键安全要点总结:

  1. ✅ 始终验证和清理用户输入
  2. ✅ 实施长度和超时限制
  3. ✅ 严格遵守消息解析规则以防止走私攻击
  4. ✅ 使用 HTTPS 保护敏感通信
  5. ✅ 谨慎处理中间方
  6. ✅ 保护服务器日志中的隐私信息

Acknowledgments (Riconoscimenti)​

Ringraziamo tutte le persone che hanno contribuito allo sviluppo della specifica HTTP/1.1.

Ringraziamo le numerose persone che hanno contribuito direttamente o indirettamente alla creazione di questo documento:

  • Roy T. Fielding (editore principale della specifica)
  • Julian Reschke (co-editore della specifica)
  • Tutti i membri del gruppo di lavoro HTTP

Ringraziamo anche gli autori della precedente specifica HTTP ([RFC2616]): Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, Tim Berners-Lee.

Ringraziamo tutti i fornitori, sviluppatori e utenti che hanno contribuito all'implementazione e al testing di HTTP/1.1.

References (参考文献)​

Normative References (规范性参考文献)​

  • [RFC2119] - Key words for use in RFCs
  • [RFC3986] - Uniform Resource Identifier (URI): Generic Syntax
  • [RFC5234] - Augmented BNF for Syntax Specifications: ABNF
  • [RFC5322] - Internet Message Format
  • [RFC7231] - HTTP/1.1 Semantics and Content
  • [RFC7232] - HTTP/1.1 Conditional Requests
  • [RFC7233] - HTTP/1.1 Range Requests
  • [RFC7234] - HTTP/1.1 Caching
  • [RFC7235] - HTTP/1.1 Authentication

Informative References (信息性参考文献)​

  • [RFC1919] - Classical versus Transparent IP Proxies
  • [RFC1945] - HTTP/1.0
  • [RFC2045] - MIME Part One
  • [RFC2616] - HTTP/1.1 (obsoleted)
  • [RFC2817] - Upgrading to TLS Within HTTP/1.1
  • [RFC2818] - HTTP Over TLS
  • [RFC3040] - Internet Web Replication and Caching Taxonomy
  • [RFC5246] - The TLS Protocol Version 1.2

✅ References 完成​

Appendix A. HTTP Version History (HTTP 版本历史)​

A.1. Changes from HTTP/1.0 (与 HTTP/1.0 的变化)​

A.1.1. Multihomed Web Servers (多宿主 Web 服务器)​

  • HTTP/1.1 要求 Host 头部字段
  • 允许单个 IP 地址托管多个域名

A.1.2. Keep-Alive Connections (保持连接)​

  • HTTP/1.1 默认使用持久连接
  • HTTP/1.0 需要显式使用 Connection: keep-alive

A.1.3. Introduction of Transfer-Encoding (引入传输编码)​

  • HTTP/1.1 引入了 Transfer-Encoding 头部字段
  • 支持分块传输编码 (chunked)

A.2. Changes from RFC 2616 (与 RFC 2616 的变化)​

主要更新包括：

  • 澄清消息解析要求
  • 改进 HTTP 语法定义
  • 增强安全考虑事项
  • 分离语义定义到独立文档 (RFC 7231-7235)

✅ Appendix A 完成​