Deal with ASCII references

rfc9114.md

@@ -688,9 +688,9 @@ To allow for better compression efficiency, the "Cookie" field ({{!RFC6265}})
 MAY be split into separate field lines, each with one or more cookie-pairs,
 before compression. If a decompressed field section contains multiple cookie
 field lines, these MUST be concatenated into a single byte string using the
-two-byte delimiter of 0x3b, 0x20 (the ASCII string "; ") before being passed
-into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a
-generic HTTP server application.
+two-byte delimiter of `; ` (ASCII 0x3b, 0x20) before being passed into a context
+other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP
+server application.
 
 ### Header Size Constraints
 
@@ -714,7 +714,7 @@ message, messages below this limit are not guaranteed to be accepted.
 ## HTTP Control Data
 
 Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where the field
-name begins with the ':' character (ASCII 0x3a).  These pseudo-header fields
+name begins with the `:` character (ASCII 0x3a).  These pseudo-header fields
 convey message control data; see {{Section 6.2 of HTTP}}.
 
 Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT generate
@@ -771,15 +771,13 @@ The following pseudo-header fields are defined for requests:
   ":path":
 
   : Contains the path and query parts of the target URI (the "path-absolute"
-    production and optionally a '?' character followed by the "query"
-    production; see {{Sections 3.3 and 3.4 of URI}}.  A request in
-    asterisk form includes the value '*' for the ":path" pseudo-header field.
+    production and optionally a `?` character (ASCII 0x3f) followed by the
+    "query" production; see {{Sections 3.3 and 3.4 of URI}}.
 
   : This pseudo-header field MUST NOT be empty for "http" or "https" URIs;
     "http" or "https" URIs that do not contain a path component MUST include a
-    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
+    value of '/'.  An OPTIONS request that does not include a path component
+    includes the value `*` (ASCII 0x2a) for the ":path" pseudo-header field; see
     {{Section 7.1 of HTTP}}.
 
 All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme",
@@ -1917,12 +1915,12 @@ or responses containing invalid field names MUST be treated as malformed
 or response containing an invalid field name into an HTTP/1.1 message.
 
 Similarly, HTTP/3 can transport field values that are not valid. While most
-values that can be encoded will not alter field parsing, carriage return (CR,
-ASCII 0x0d), line feed (LF, ASCII 0x0a), and the zero character (NUL, ASCII
-0x00) 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 HTTP}}.
+values that can be encoded will not alter field parsing, carriage return (ASCII
+0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) 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 HTTP}}.
 
 ## Cacheability of Pushed Responses