need to cover canonicalization issues around mismatching.. minimally case, but I wonder if fully-qualified is an issue.

I am not sure if we should require every endpoint to see if there is a mismatch between the authority of the absolute form the value of the host header field. It's going to be costly and complex, because it requires canonicalization (as @mcmanus points out).

And assuming that we do not require that, we need to specify which one takes precedence when absolute form is being used. For this point, I do not think there is a necessity to change the current approach (i.e., give precedence to the value of the absolute form).

Is there a recommendation we might make here? "If an intermediary uses the authority from a URI in the absolute form, it MUST erase any Host header field before forwarding the request." For instance.

One reasonable solution could be to indicate that if an intermediary or server wants to use the authority from the URI, then it must use the host part from the Host header field. This at least enforces the use of the most controlled field which is expected to have been checked, de-duplicated, possibly matched against SNI etc. This would clarify the role of the Host header field in the request.

Also I think that one reason for the ambiguity is that we all have to support HTTP/1.0 requests and make decisions when writing the code. As such we all implement fallbacks and default behaviours which tend to be the same between versions, and that's where we should probably indicate what to do depending on the version in the request. For example :

• for HTTP/1.1 and above, since Host is mandatory it must be used ;
• for HTTP/1.0, Host is optional, so it must be used if present otherwise fall back to the authority in the URI

@wtarreau My understanding is that RFC 7230; section 5.4 instructs a proxy to use the value found in the absolute-form rather than the value of the host header field, regardless of the HTTP version being specified by the client.

I think we should keep that as-is. Orthogonal to that, I think it's a good idea to clarify what a proxy should do (as @martinthomson suggests), and/or to allow a server to reject requests that carry contradicting values (between the authority of the absolute form and the value of the host header field).

in the current draft we have:

When a proxy receives a request with an absolute-form of request-target, the proxy must ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request must generate a new Host field value based on the received request-target rather than forward the received Host field value.

... which seems to cover proxies. Non-proxy intermediaries can of course do what they like with Host (and often do).

This doesn't give any advice to origin servers about which one to prefer when it is received, however. We could add something like:

When an origin server receives a request with an absolute-form of request-target, the origin server must ignore the received Host header field (if any) and instead use the host information of the request-target.

Thoughts?