Original text:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del>  <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del>  For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del>  7.1.3.

Reviewer comments:
Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!

Revised text:
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple  <ins> host names. </ins>  <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:  <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.