Is it correct behaviour for a client to trim the port when following HTTP 302

Question

Is it correct behaviour for an HTTP client to trim the :443 port from a 302 redirect?

I notice that web browsers do this. So, if redirected to https://website.domain.com:443 they actually subsequently request https://website.domain.com. I coudln't find a clear answer in the standard.

I am writing an iOS App that is interacting with an HTTP authentication server that is explicitly adding :443 to a 302 redirect. My app follows the redirect verbatim, but unfortunately this makes the SSO Login server reject the authentication attempt because it's performing hostname verification.

It deems login.domain.com:443 to be different from login.domain.com.

The flow is:

1. Request https://website.domain.com/protected_page
2. Am redirected to https://login.domain.com
3. login.domain.com redirects to https://login.domain.com:443/auth
   1. At this point a browser would redirect to https://login.domain.com/auth
   2. My App redirects verbatim to https://login.domain.com:443/auth

Is my App's behaviour correct?

Is the login server's assertion that login.domain.com:443 is not the same domain as login.domain.com correct?

Answer 1

Well, you have come across a design fault in the login server.

RFC 3986, section 3.2.3 states that

URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default.

I.e. any URI parser should realize that if the port is omitted, default value of the port must be used, consequently https://login.domain.com and https://login.domain.com:443 are the same URI component.

What you can do is alter the URI if this is needed for login server to accept it.