Допустимо ли изменять текст, отправляемый с кодом статуса HTTP? - PullRequest
8 голосов
/ 12 ноября 2011

Я реализую «режим тестирования» на моем веб-сайте, который запрещает доступ к определенным страницам во время их разработки, делая их доступными только для администраторов для частного тестирования.Я планировал использовать код состояния 401, поскольку страница существует , но им не разрешено ее использовать, и они могут или не могут проходить проверку подлинности, но все же только некоторые пользователи (в основном я) будутразрешен доступ к странице.

Мне интересно, имеет ли значение текст после части HTTP/1.1 401?Должно ли это быть Unauthorized или это может быть то, что вы хотите поставить после него, если 401 все еще подходит для ошибки?Я хотел отправить сообщение, такое как Temporarily Unavailable, чтобы указать, что страница, как правило, доступна всем посетителям, но находится в процессе реконструкции и временно недоступна.Должен ли я сделать это или нет?

Ответы [ 3 ]

7 голосов
/ 12 ноября 2011

Вы можете изменить их.

Сообщения о состоянии (технически называемые «фразами разума») являются только рекомендациями и «МОГУТ быть изменены без влияния на протокол)».

См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1

Однако вы ДОЛЖНЫ :-) по-прежнему правильно использовать коды и давать содержательные сообщения. Используйте 401, только если ваше состояние соответствует требованиям RFC, 401 должно быть.

2 голосов
/ 12 ноября 2011

Да, фраза причины может быть изменена. Это не влияет на значение сообщения.

Но если вам нужно сказать «временно недоступно», вам нужно сделать это 5xx (серверным) кодом. Кажется, здесь 503 (см. RFC 2616, раздел 10.5.4 ).

1 голос
/ 12 ноября 2011

Вы МОЖЕТЕ изменить текст (очень немногие http-клиенты обращают на него внимание), но лучше использовать наиболее подходящий код ответа.В конце концов, указание причины сбоя заключается в том, как различные коды ответов предназначались для использования.

Возможно, это подходит:

404 Не найдено Запрошенный ресурс не найден, нобыть доступным снова в будущем. [2]Последующие запросы клиента допустимы.

...