Я использую этот код. У меня есть запросы обратного проксирования nginx к двум отдельным HTTP-серверам. Один обрабатывает запросы неаутентифицированных пользователей, а второй обрабатывает запросы аутентифицированных пользователей. Проблема в данном конкретном случае заключается в том, что первый сервер определяет, аутентифицирован ли пользователь. Пожалуйста, не спрашивайте почему.
Итак, если первый сервер определяет, что пользователь аутентифицирован, он отвечает 418 I'm a teapot. Затем NGINX перенаправляет внутренний трафик на второй сервер. Что касается браузера, то это был единичный запрос.
Это в духе кода HTCPCP 418 , потому что, если вы попытаетесь BREW с помощью чайника, соответствующий ответ будет: «Я не из тех, кто может обработать этот запрос, но могут быть и другие». .. Другими словами, «Я чайник. Найди кофеварку». (второй сервер - кофеварка).
В конечном итоге, хотя 418 явно не определен в RFC 7231 , он по-прежнему охвачен4xx (Client Error) .
6. Коды состояния ответа
4xx (ошибка клиента): запрос содержит неверный синтаксис или не может быть выполнен
6.5. Ошибка клиента 4xx
Класс кода состояния 4xx (ошибка клиента) указывает на то, что клиент совершил ошибку. За исключением ответа на запрос HEAD, серверу СЛЕДУЕТ послать представление, содержащее объяснение ситуации с ошибкой и того, является ли это временным или постоянным состоянием. Эти коды состояния применимы к любому методу запроса. Пользовательские агенты ДОЛЖНЫ отображать любое включенное представление пользователю.
У меня есть сторонний провайдер (очень плохой), который ответил бы 418, если бы вы пропустили заголовок Accept. Я всегда думал, что это потому, что они были просто плохими, но на самом деле это объясняет, что происходило. Тем не менее, они все еще не прощают им утечку этого кода статуса со своих серверов
Хоффманн,
7
@Hoffmann Возможно, им было уместно ответить 400 Bad Request или 415 Unsupported Media Type, любой код 4xx представляет ошибку клиента, поэтому может быть интерпретирован таким образом.
wizulus
1
Этот код состояния добавлен в модуль стандартной библиотеки httpв Python 3.9.
BramAppel
56
Код ответа HTTP 418 был первоначально определен в протоколах RFC 2324 («Протокол управления гипертекстовым кофейником (HTCPCP / 1.0)») и RFC 7168 («Протокол управления гипертекстовым кофейником для устройств для отливания чая (HTCPCP-TEA)»).
Этот код был определен в 1998 году как одна из традиционных шуток IETF первоапрельских шуток в RFC 2324 , Hyper Text Coffee Pot Control Protocol , и не ожидается, что он будет реализован на реальных HTTP-серверах . RFC указывает, что этот код должен возвращаться чайниками, которых просят заварить кофе. Этот статус HTTP используется в качестве пасхального яйца на некоторых веб-сайтах, включая Google.com .
@Evert, что влияет на то, становится ли что-то в RFC "официальным"? Не могли бы вы превратить свой комментарий в ответ, чтобы я мог его принять?
Mohan
@Mohan Мне не нравится пытаться написать IETF и процесс стандартизации в небольшом комментарии, потому что я, вероятно, ошибаюсь. В конечном итоге я считаю, что это зависит от соответствующих рабочих групп IETF.
Evert
12
Да, я могу подтвердить, что видел, как HTTP 418 возвращается с реального производственного сервера. Он существует.
Класс WebException будет отображать любой код ответа и текст статуса, возвращенные в запросе. Если первая строка заголовка ответа была «432 One Zero», сообщение было бы «Удаленный сервер возвратил ошибку: (432) One Zero». Было бы более полезно знать, какой сервер вы вызывали, когда возникла эта ошибка, и какое программное обеспечение на нем было запущено.
wizulus
3
Да, это «настоящий» код в том смысле, что он был фактически опубликован как официальный RFC инженерной группой Интернета, но этот RFC был опубликован 1 апреля и задуман как первоапрельская шутка (вместе с остальной частью Hyper Text Coffee Pot Control Протокол), а не для законной реализации. Вот почему большинство сайтов используют его как пасхальное яйцо, но в остальном избегают. Как отмечено в этом комментарии , часто бывают более подходящие статусы, такие как 400 (неверный запрос).
Я думаю, что безопаснее рассматривать 418 как зарезервированный код, который когда-то имел полуофициальное значение, но теперь официально «неназначенный».
Я предполагаю, что исторически что-то думали об этих кодах иначе, чем сейчас. Сегодня это звучит бессмысленно и забавно; наверное не было?
Другими словами, я бы не стал использовать этот код.
Ответы:
Я использую этот код. У меня есть запросы обратного проксирования nginx к двум отдельным HTTP-серверам. Один обрабатывает запросы неаутентифицированных пользователей, а второй обрабатывает запросы аутентифицированных пользователей. Проблема в данном конкретном случае заключается в том, что первый сервер определяет, аутентифицирован ли пользователь. Пожалуйста, не спрашивайте почему.
Итак, если первый сервер определяет, что пользователь аутентифицирован, он отвечает
418 I'm a teapot
. Затем NGINX перенаправляет внутренний трафик на второй сервер. Что касается браузера, то это был единичный запрос.Это в духе кода HTCPCP 418 , потому что, если вы попытаетесь BREW с помощью чайника, соответствующий ответ будет: «Я не из тех, кто может обработать этот запрос, но могут быть и другие». .. Другими словами, «Я чайник. Найди кофеварку». (второй сервер - кофеварка).
В конечном итоге, хотя 418 явно не определен в RFC 7231 , он по-прежнему охвачен
4xx (Client Error)
.источник
http
в Python 3.9.Код ответа HTTP 418 был первоначально определен в протоколах RFC 2324 («Протокол управления гипертекстовым кофейником (HTCPCP / 1.0)») и RFC 7168 («Протокол управления гипертекстовым кофейником для устройств для отливания чая (HTCPCP-TEA)»).
Согласно Википедии: Список кодов состояния HTTP: # 418
источник
Да, я могу подтвердить, что видел, как HTTP 418 возвращается с реального производственного сервера. Он существует.
источник
Да, это «настоящий» код в том смысле, что он был фактически опубликован как официальный RFC инженерной группой Интернета, но этот RFC был опубликован 1 апреля и задуман как первоапрельская шутка (вместе с остальной частью Hyper Text Coffee Pot Control Протокол), а не для законной реализации. Вот почему большинство сайтов используют его как пасхальное яйцо, но в остальном избегают. Как отмечено в этом комментарии , часто бывают более подходящие статусы, такие как 400 (неверный запрос).
Примечательно, что, по словам Ларри Масинтера (автора RFC, на который ссылается Википедия), рассматриваемое расширение HTTP действительно служит (сатирической) цели: «оно идентифицирует многие способы ненадлежащего расширения HTTP».
источник
Я думаю, что безопаснее рассматривать 418 как зарезервированный код, который когда-то имел полуофициальное значение, но теперь официально «неназначенный».
Я предполагаю, что исторически что-то думали об этих кодах иначе, чем сейчас. Сегодня это звучит бессмысленно и забавно; наверное не было?
Другими словами, я бы не стал использовать этот код.
источник