Default value for Host

[martinthomson]

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:

Otherwise, the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port number differs from the default port for the target URI's scheme, then a colon (":") and the incoming port number (in decimal form) are appended to the authority component.

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 -semantics. And that section is a bit weaselly in that regard, using a "SHOULD...unless".

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.

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 this, which might be read to imply that Host truly is mandatory:

A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form

The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.

[royfielding]

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).

[royfielding]

If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory).

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.

[martinthomson]

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).