Каков правильный HTTP-ответ для отправки запросов, требующих SSL/TLS

Я разрабатываю API RESTful, где некоторые вызовы являются общедоступными через HTTP, а некоторые требуют ключа API и шифрования через HTTPS. Я обсуждаю, какой код ответа следует отправить, если HTTP-запрос отправляется в один из частных ресурсов. Пока что единственная, которая выпрыгивает на меня, 412 - Precondition Failed, но стандарт указывает, что предварительное условие навязывается запрашивающим, а не сервером.

Есть ли подходящий код ответа для этого условия или мне просто нужно дать и сделать 400?

Ответ 2

Я не могу сказать, широко ли это принято HTTP-клиентами, но, строго говоря, RFC, сервер должен ответить:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Источник:
http://tools.ietf.org/html/rfc2817#section-4.2

Ответ 3

Соответствующий код ошибки для возврата будет похож на 403.4 - требуется SSL.

Хотя это явно не описано в RFC для HTTP 1.1, это поведение соответствует требованиям, изложенным там:

Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. Если метод запроса не был HEAD, и сервер хочет сообщить, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в сущности. Если сервер не желает предоставлять эту информацию клиенту, вместо этого может использоваться код состояния 404 (Not Found).

В некоторых случаях может оказаться полезным добавление собственного субкода (как в примере с SSL), но поскольку этот субкод не будет иметь смысла для третьих сторон, я бы рекомендовал против него.

Итак, ваше окончательное сообщение об ошибке будет примерно как "403 - частный ресурс". Обратите внимание, что даже в случае отсутствия ключа API "401 - неавторизованный" не следует использовать, если только ваш ключ API не может быть передан в поле заголовка WWW-Authenticate.

Ответ 4

Возврат 403 с фразой " HTTPS Обязательный" кажется практичным вариантом и тем, что я использую.

см. https://en.wikipedia.org/wiki/HTTP_403

Перенаправление REST Api не является хорошей идеей, особенно, поскольку вы, возможно, не знаете, как или что потребляет вашу услугу.

Ответ 5

Просто отправьте перенаправление на соответствующий https: URI.

UPDATE

Неправильный ответ - см. комментарии ниже