Take port into account for the signature

[michivi]

Description

This PR instructs the servant-hmac-auth client code to take the remote HTTP port into account in the generated HMAC signatures for the following cases:

• Targeted http port other than 80
• Targeted https port other than 443

Technical details

The HMAC signature takes into account both the Host http header and the requested URL (from host to query string and everything in between, including any non-standard port).

Before that PR, the client code actually only took the host into account, both for the always-overwritten Host header and for the URL used for the signature. This would work if the client application targets a remote endpoint on a standard port (80 for http, 443 for https) as the port is optional in that case. However, this fails on non-standard port as it would then be required to be explicit for both the HTTP header and the URL. By ignoring the port, the library would generate a signature that wouldn't be recognized as valid by the remote server if the latter takes the port into account.

This PR forces the library to take the port into account when the targeted port is not standard. However, should the client application use an explicit Host header, this one will be used instead.

The server code is not impacted as it always uses the Host HTTP header.

Consequences

Servers are not impacted by the PR.

Clients only sending requests to servers on a standard port (80 for http and 443 for https) are not affected.

Clients that were sending requests to servers which were modified not to take the port into account needs to be updated to do so.

[turboMaCk]

I don't know this codebase much but are you sure this will be reliable even when server is behind the reverse proxy that accepts https trafic but forwards unecrypted http trafic to haskell server?

[turboMaCk]

I guess this won't be a problem since this code is in client to server but I'm rather asking.

[michivi]

I don't think unencrypted traffic will be an issue. With HMAC, we're more concerned about authentication and integrity rather than confidentiality. For the later, https should be used anyway. If https is not used, I guess confidentiality is not that important 😀

[kahlil29]

Looks good to me 👍🏻

[michivi]

Thank you all for the reviews.
Unless there's an absolute necessity for the merge, I'll delay it just a little until another PR regarding the hashing of the request's content is ready. While they're not related, it'll take less time to handle both PRs.