Track httpwg/http-core#907: SEMANTICS->HTTP

rfc9114.md

@@ -90,7 +90,7 @@ subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
 
 # Introduction
 
-HTTP semantics ({{!SEMANTICS=I-D.ietf-httpbis-semantics}}) are used for a broad
+HTTP semantics ({{!HTTP=I-D.ietf-httpbis-semantics}}) are used for a broad
 range of services on the Internet. These semantics have most commonly been used
 with HTTP/1.1 and HTTP/2.  HTTP/1.1 has been used over a variety of transport
 and session layers, while HTTP/2 has been used primarily with TLS over TCP.
@@ -267,11 +267,11 @@ stream:
 stream error:
 : An application-level error on the individual stream.
 
-The term "content" is defined in {{Section 6.4 of SEMANTICS}}.
+The term "content" is defined in {{Section 6.4 of HTTP}}.
 
 Finally, the terms "resource", "message", "user agent", "origin server",
 "gateway", "intermediary", "proxy", and "tunnel" are defined in {{Section 3 of
-SEMANTICS}}.
+HTTP}}.
 
 Packet diagrams in this document use the format defined in
 {{Section 1.3 of QUIC-TRANSPORT}} to illustrate the order and size of fields.
@@ -286,13 +286,13 @@ determined to be the most appropriate response for that request given the state
 of the target resource at the time of response message origination by (or at the
 direction of) the origin server identified within the target URI.  Locating an
 authoritative server for an HTTP URI is discussed in
-{{Section 4.3 of SEMANTICS}}.
+{{Section 4.3 of HTTP}}.
 
 The "https" scheme associates authority with possession of a certificate that
 the client considers to be trustworthy for the host identified by the authority
 component of the URI.  Upon receiving a server certificate in the TLS handshake,
 the client MUST verify that the certificate is an acceptable match for the URI's
-origin server using the process described in {{Section 4.3.4 of SEMANTICS}}. If
+origin server using the process described in {{Section 4.3.4 of HTTP}}. If
 the certificate cannot be verified with respect to the URI's origin server, the
 client MUST NOT consider the server authoritative for that origin.
 
@@ -384,7 +384,7 @@ Once a connection to a server endpoint exists, this connection MAY be reused for
 requests with multiple different URI authority components.  To use an existing
 connection for a new origin, clients MUST validate the certificate presented by
 the server for the new origin server using the process described in {{Section
-4.3.4 of SEMANTICS}}.  This implies that clients will need to retain the
+4.3.4 of HTTP}}.  This implies that clients will need to retain the
 server certificate and any additional information needed to verify that
 certificate; clients that do not do so will be unable to reuse the connection
 for additional origins.
@@ -415,7 +415,7 @@ processed and gracefully complete or terminate any necessary remaining tasks.
 A server that does not wish clients to reuse HTTP/3 connections for a particular
 origin can indicate that it is not authoritative for a request by sending a 421
 (Misdirected Request) status code in response to the request; see {{Section 7.4
-of SEMANTICS}}.
+of HTTP}}.
 
 
 # HTTP Request Lifecycle
@@ -426,7 +426,7 @@ A client sends an HTTP request on a request stream, which is a client-initiated
 bidirectional QUIC stream; see {{request-streams}}.  A client MUST send only a
 single request on a given stream.  A server sends zero or more interim HTTP
 responses on the same stream as the request, followed by a single final HTTP
-response, as detailed below. See {{Section 15 of SEMANTICS}} for a description
+response, as detailed below. See {{Section 15 of HTTP}} for a description
 of interim and final HTTP responses.
 
 Pushed responses are sent on a server-initiated unidirectional QUIC stream; see
@@ -448,7 +448,7 @@ An HTTP message (request or response) consists of:
 3. optionally, the trailer section, if present, sent as a single HEADERS frame.
 
 Header and trailer sections are described in {{Sections 6.3 and 6.5 of
-SEMANTICS}}; the content is described in {{Section 6.4 of SEMANTICS}}.
+HTTP}}; the content is described in {{Section 6.4 of HTTP}}.
 
 Receipt of an invalid sequence of frames MUST be treated as a connection error
 of type H3_FRAME_UNEXPECTED; see {{errors}}.  In particular, a DATA frame before
@@ -476,7 +476,7 @@ Transfer codings (see {{Section 6.1 of HTTP11}}) are not defined for HTTP/3;
 the Transfer-Encoding header field MUST NOT be used.
 
 A response MAY consist of multiple messages when and only when one or more
-interim responses (1xx; see {{Section 15.2 of SEMANTICS}}) precede a final
+interim responses (1xx; see {{Section 15.2 of HTTP}}) precede a final
 response to the same request.  Interim responses do not contain content
 or trailer sections.
 
@@ -510,13 +510,13 @@ continue sending the body of the request and close the stream normally.
 ### Field Formatting and Compression {#header-formatting}
 
 HTTP messages carry metadata as a series of key-value pairs called "HTTP
-fields"; see {{Sections 6.3 and 6.5 of SEMANTICS}}. For a listing of registered
-HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
+fields"; see {{Sections 6.3 and 6.5 of HTTP}}. For a listing of registered HTTP
+fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
 maintained at [](https://www.iana.org/assignments/http-fields/).
 
 Field names are strings containing a subset of ASCII characters. Properties of
 HTTP field names and values are discussed in more detail in {{Section 5.1 of
-SEMANTICS}}. As in HTTP/2, characters in field names MUST be converted to
+HTTP}}. As in HTTP/2, characters in field names MUST be converted to
 lowercase prior to their encoding. A request or response containing uppercase
 characters in field names MUST be treated as malformed ({{malformed}}).
 
@@ -532,7 +532,7 @@ HTTP/3 request header; when it is, it MUST NOT contain any value other than
 
 An intermediary transforming an HTTP/1.x message to HTTP/3 MUST remove
 connection-specific header fields as discussed in {{Section 7.6.1 of
-SEMANTICS}}, or their messages will be treated by other HTTP/3 endpoints as
+HTTP}}, or their messages will be treated by other HTTP/3 endpoints as
 malformed ({{malformed}}).
 
 #### Pseudo-Header Fields
@@ -563,7 +563,7 @@ The following pseudo-header fields are defined for requests:
 
   ":method":
 
-  : Contains the HTTP method ({{Section 9 of SEMANTICS}})
+  : Contains the HTTP method ({{Section 9 of HTTP}})
 
   ":scheme":
 
@@ -585,7 +585,7 @@ The following pseudo-header fields are defined for requests:
   : To ensure that the HTTP/1.1 request line can be reproduced accurately, this
     pseudo-header field MUST be omitted when translating from an HTTP/1.1
     request that has a request target in origin or asterisk form; see {{Section
-    7.1 of SEMANTICS}}.  Clients that generate HTTP/3 requests directly
+    7.1 of HTTP}}.  Clients that generate HTTP/3 requests directly
     SHOULD use the ":authority" pseudo-header field instead of the Host field.
     An intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a
     Host field if one is not present in a request by copying the value of the
@@ -603,7 +603,7 @@ The following pseudo-header fields are defined for requests:
     value of '/'.  The exception to this rule is an OPTIONS request for an
     "http" or "https" URI that does not include a path component; these MUST
     include a ":path" pseudo-header field with a value of '*'; see
-    {{Section 7.1 of SEMANTICS}}.
+    {{Section 7.1 of HTTP}}.
 
 All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme",
 and ":path" pseudo-header fields, unless the request is a CONNECT request; see
@@ -624,7 +624,7 @@ HTTP/3 does not define a way to carry the version identifier that is included in
 the HTTP/1.1 request line.
 
 For responses, a single ":status" pseudo-header field is defined that carries
-the HTTP status code; see {{Section 15 of SEMANTICS}}.  This pseudo-header
+the HTTP status code; see {{Section 15 of HTTP}}.  This pseudo-header
 field MUST be included in all responses; otherwise, the response is malformed
 (see {{malformed}}).
 
@@ -662,7 +662,7 @@ as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An
 implementation that has received this parameter SHOULD NOT send an HTTP message
 header that exceeds the indicated size, as the peer will likely refuse to
 process it.  However, an HTTP message can traverse one or more intermediaries
-before reaching the origin server; see {{Section 3.7 of SEMANTICS}}.  Because
+before reaching the origin server; see {{Section 3.7 of HTTP}}.  Because
 this limit is applied separately by each implementation that processes the
 message, messages below this limit are not guaranteed to be accepted.
 
@@ -706,7 +706,7 @@ idempotent actions such as GET, PUT, or DELETE can be safely retried; a client
 SHOULD NOT automatically retry a request with a non-idempotent method unless it
 has some means to know that the request semantics are idempotent
 independent of the method or some means to detect that the original request was
-never applied.  See {{Section 9.2.2 of SEMANTICS}} for more details.
+never applied.  See {{Section 9.2.2 of HTTP}} for more details.
 
 ### Malformed Requests and Responses {#malformed}
 
@@ -722,7 +722,7 @@ frames but is invalid due to:
 - the inclusion of invalid characters in field names or values.
 
 A request or response that is defined as having content when it contains a
-Content-Length header field ({{Section 6.4.1 of SEMANTICS}}),
+Content-Length header field ({{Section 6.4.1 of HTTP}}),
 is malformed if the value of a Content-Length header field does not equal the
 sum of the DATA frame lengths received. A response that is defined as never
 having content, even when a Content-Length is present, can have a non-zero
@@ -744,7 +744,7 @@ permissive can expose implementations to these vulnerabilities.
 
 The CONNECT method requests that the recipient establish a tunnel to the
 destination origin server identified by the request-target; see {{Section 9.3.6
-of SEMANTICS}}. It is primarily used with HTTP proxies to establish a TLS
+of HTTP}}. It is primarily used with HTTP proxies to establish a TLS
 session with an origin server for the purposes of interacting with "https"
 resources.
 
@@ -758,7 +758,7 @@ A CONNECT request MUST be constructed as follows:
 - The ":scheme" and ":path" pseudo-header fields are omitted
 - The ":authority" pseudo-header field contains the host and port to connect to
   (equivalent to the authority-form of the request-target of CONNECT requests;
-  see {{Section 7.1 of SEMANTICS}}).
+  see {{Section 7.1 of HTTP}}).
 
 The request stream remains open at the end of the request to carry the data to
 be transferred.  A CONNECT request that does not conform to these restrictions
@@ -767,7 +767,7 @@ is malformed; see {{malformed}}.
 A proxy that supports CONNECT establishes a TCP connection ({{!RFC0793}}) to the
 server identified in the ":authority" pseudo-header field.  Once this connection
 is successfully established, the proxy sends a HEADERS frame containing a 2xx
-series status code to the client, as defined in {{Section 15.3 of SEMANTICS}}.
+series status code to the client, as defined in {{Section 15.3 of HTTP}}.
 
 All DATA frames on the stream correspond to data sent or received on the TCP
 connection. The payload of any DATA frame sent by the client is transmitted by
@@ -800,13 +800,13 @@ set.
 
 Since CONNECT creates a tunnel to an arbitrary server, proxies that support
 CONNECT SHOULD restrict its use to a set of known ports or a list of safe
-request targets; see {{Section 9.3.6 of SEMANTICS}} for more details.
+request targets; see {{Section 9.3.6 of HTTP}} for more details.
 
 ## HTTP Upgrade
 
 HTTP/3 does not support the HTTP Upgrade mechanism ({{Section 7.8 of
 SEMANTICS}}) or the 101 (Switching Protocols) informational status code
-({{Section 15.2.2 of SEMANTICS}}).
+({{Section 15.2.2 of HTTP}}).
 
 ## Server Push
 
@@ -850,8 +850,8 @@ be fulfilling a previous promise.
 Not all requests can be pushed.  A server MAY push requests that have the
 following properties:
 
-- cacheable; see {{Section 9.2.3 of SEMANTICS}}
-- safe; see {{Section 9.2.1 of SEMANTICS}}
+- cacheable; see {{Section 9.2.3 of HTTP}}
+- safe; see {{Section 9.2.1 of HTTP}}
 - does not include a request body or trailer section
 
 The server MUST include a value in the ":authority" pseudo-header field for
@@ -1815,7 +1815,7 @@ apply to {{QUIC-TRANSPORT}} and are discussed in that document.
 ## Server Authority
 
 HTTP/3 relies on the HTTP definition of authority. The security considerations
-of establishing authority are discussed in {{Section 17.1 of SEMANTICS}}.
+of establishing authority are discussed in {{Section 17.1 of HTTP}}.
 
 ## Cross-Protocol Attacks
 
@@ -1831,7 +1831,7 @@ authenticated transports.
 ## Intermediary-Encapsulation Attacks
 
 The HTTP/3 field encoding allows the expression of names that are not valid
-field names in the syntax used by HTTP ({{Section 5.1 of SEMANTICS}}). Requests
+field names in the syntax used by HTTP ({{Section 5.1 of HTTP}}). Requests
 or responses containing invalid field names MUST be treated as malformed
 ({{malformed}}).  Therefore, an intermediary cannot translate an HTTP/3 request
 or response containing an invalid field name into an HTTP/1.1 message.
@@ -1842,7 +1842,7 @@ ASCII 0x0d), line feed (LF, ASCII 0x0d), and the zero character (NUL, ASCII
 0x0d) might be exploited by an attacker if they are translated verbatim. Any
 request or response that contains a character not permitted in a field value
 MUST be treated as malformed ({{malformed}}).  Valid characters are defined by
-the "field-content" ABNF rule in {{Section 5.5 of SEMANTICS}}.
+the "field-content" ABNF rule in {{Section 5.5 of HTTP}}.
 
 ## Cacheability of Pushed Responses
 
@@ -1939,7 +1939,7 @@ terminates.
 Compression can allow an attacker to recover secret data when it is compressed
 in the same context as data under attacker control. HTTP/3 enables compression
 of fields ({{header-formatting}}); the following concerns also apply to the use
-of HTTP compressed content-codings; see {{Section 8.4.1 of SEMANTICS}}.
+of HTTP compressed content-codings; see {{Section 8.4.1 of HTTP}}.
 
 There are demonstrable attacks on compression that exploit the characteristics
 of the web (e.g., {{BREACH}}).  The attacker induces multiple requests