Code change:
3.3. <del> Since the request-target often contains only part of the user agent's target URI, a server constructs its value to properly service the request (target.resource). </del> <ins> The target URI is the </ins> <del> If the </del> <ins> when the request-target is in </ins> <del> is in </del> <ins> . In that case, a server will parse the URI into its generic components for further evaluation. </ins> <del> , the target URI is the same as the request-target.  Otherwise, the target URI is constructed as follows: </del> <ins> Otherwise, the server reconstructs the target URI from the connection context and various parts of the request message in order to identify the target resource (target.resource): </ins> <del> Example 1: the following message received over an insecure TCP connection </del> <ins> Example 1: the following message received over a secure connection </ins> has a target URI of <del> Example 2: the following message received over a secured connection </del> <ins> Example 2: the following message received over an insecure connection </ins> has a target URI of <del> Recipients of an HTTP/1.0 request that lacks a header field might need to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess the target URI's authority component. </del> <ins> If the target URI's authority component is empty and its URI scheme requires a non-empty authority (as is the case for "http" and "https"), the server can reject the request or determine whether a configured default applies that is consistent with the incoming connection's context.  Context might include connection details like address and port, what security has been applied, and locally-defined information specific to that server's configuration.  An empty authority is replaced with the configured default before further processing of the request. Supplying a default name for authority within the context of a secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default.  A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client. Note that reconstructing the client's target URI is only half of the process for identifying a target resource.  The other half is determining whether that target URI identifies a resource for which the server is willing and able to send a response, as defined in routing.reject. </ins> 4.

Related discussion:
text: ... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again