Правильное поведение клиента для обрезания порта при выполнении HTTP 302

Question

Правильно ли поведение клиента HTTP для обрезания: 443-порта из перенаправления 302?

Я замечаю, что веб-браузеры делают это. Поэтому, если они перенаправлены на https://website.domain.com:443, они фактически запрашивают https://website.domain.com. Я не нашел четкого ответа в стандарте.

Я пишу приложение iOS, которое взаимодействует с сервером аутентификации HTTP, который явно добавляет: 443 к перенаправлению 302. Мое приложение следует перенаправлять дословно, но, к сожалению, это делает сервер входа в систему SSO отклонен попыткой аутентификации, поскольку он выполняет проверку имени хоста.

Он считает, что login.domain.com:443 отличается от login.domain.com.

Течение:

1. Запрос https://website.domain.com/protected_page
2. Am перенаправлены https://login.domain.com
3. login.domain.com перенаправляет к https://login.domain.com:443/auth
   1. На данный момент браузер будет перенаправлять на https://login.domain.com/auth
   2. Мое приложение перенаправляет до https://login.domain.com:443/auth

Правильно ли поведение моего приложения?

Является ли утверждение входа в систему, что login.domain.com:443 - это не тот же домен, что и login.domain.com?

Answer 1

Ну, вы столкнулись с ошибкой дизайна на сервере входа.

RFC 3986, раздел 3.2.3 утверждает, что

производители и нормализаторы URI должен опустить компонент порта и его «:» разделитель, если порт пуст или если его значение будет одним из же, что по умолчанию.

I.e. любой анализатор URI должен понимать, что если порт опущен, необходимо использовать значение по умолчанию порта, поэтому https://login.domain.com и https://login.domain.com:443 являются одним и тем же компонентом URI.

Что вы можете сделать, это изменить URI, если это необходимо для того, чтобы сервер регистрации мог его принять.