Содержание

Коды ответов WordPress REST API

REST API использует строку состояния в HTTP ответе (статус ответа), чтобы информировать Клиентов о результате запроса.

Вообще HTTP определяет 40 стандартных кодов состояния (статусов ответа), которые делятся на пять категорий. Ниже выделены только те коды состояния, которые часто используются в REST API.

КатегорияОписание
1xx: ИнформацияВ этот класс содержит заголовки информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков. Серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам.
2xx: УспехЭтот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят.
3xx: ПеренаправлениеКоды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI.
Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям.
4xx: Ошибка клиентаКласс кодов 4xx предназначен для указания ошибок со стороны клиента.
5xx: Ошибка сервераКоды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос.

Звездочкой * помечены популярные (часто используемые) коды ответов.

200 * (OK)

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:

  • GET Получен объект, соответствующий запрошенному ресурсу.
  • HEAD Получены поля заголовков, соответствующие запрошенному ресурсу, тело ответа пустое.
  • POST Запрошенное действие выполнено.

201 * (Created — Создано)

REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.

Ссылка (URL) на новый ресурс может быть в теле ответа или в поле заголовка ответа Location.

Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).

202 (Accepted — Принято)

Ответ 202 обычно используется для действий, которые занимают много времени для обработки и не могут быть выполнены сразу. Это означает, что запрос принят к обработке, но обработка не завершена.

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

Сущность, возвращаемая с этим ответом, должна содержать указание на текущее состояние запроса и указатель на монитор состояния (расположение очереди заданий) или некоторую оценку того, когда пользователь может ожидать выполнения запроса.

203 (Non-Authoritative Information — Неавторитетная информация)

Предоставленная информация взята не из оригинального источника (а, например, из кэша, который мог устареть, или из резервной копии, которая могла потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предоставленная информация может совпадать, а может и не совпадать с оригинальными данными.

204 * (No Content — Нет контента)

Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.

API может также отправить 204 статус в ответ на GET запрос, чтобы указать, что запрошенный ресурс существует, но не имеет данных для добавления их в тело ответа.

Ответ 204 не должен содержать тело сообщения и, таким образом, всегда завершается первой пустой строкой после полей заголовка.

205 — (Reset Content — Сброшенное содержимое)

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяется для возврата в начальное состояние формы ввода данных на клиенте.

206 — (Partial Content — Частичное содержимое)

Сервер выполнил часть GET запроса ресурса. Запрос ДОЛЖЕН был содержать поле заголовка Range (секция 14.35), который указывает на желаемый диапазон и МОГ содержать поле заголовка If-Range (секция 14.27), который делает запрос условным.

Запрос ДОЛЖЕН содержать следующие поля заголовка:

  • Либо поле Content-Range (секция 14.16), который показывает диапазон, включённый в этот запрос, либо Content-Type со значением multipart/byteranges, включающими в себя поля Content-Range для каждой части. Если в заголовке запроса есть поле Content-Length, его значение ДОЛЖНО совпадать с фактическим количеством октетов, переданных в теле сообщения.
  • Date
  • ETag и/или Content-Location, если ранее был получен ответ 200 на такой же запрос.
  • Expires, Cache-Control, и/или Vary, если значение поля изменилось с момента отправления последнего такого же запроса

Если ответ 206 — это результат выполнения условного запроса, который использовал строгий кэш-валидатор (подробнее в секции 13. 3.3), в ответ НЕ СЛЕДУЕТ включать какие-либо другие заголовки сущности. Если такой ответ — результат выполнения запроса If-Range, который использовал «слабый» валидатор, то ответ НЕ ДОЛЖЕН содержать другие заголовки сущности; это предотвращает несоответствие между закэшированными телами сущностей и обновлёнными заголовками. В противном случае ответ ДОЛЖЕН содержать все заголовки сущностей, которые вернули статус 200 (OK) на тот же запрос.

Кэш НЕ ДОЛЖЕН объединять ответ 206 с другими ранее закэшированными данными, если поле ETag или Last-Modified в точности не совпадают (подробнее в секции 16.5.4)

Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы 206 (Partial).

300 — (Multiple Choices — Несколько вариантов)

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю.

Если это не запрос HEAD, ответ ДОЛЖЕН включать объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведённых в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако эта спецификация не определяет никакого стандарта для автоматического выбора.

Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; агент пользователя МОЖЕТ использовать заголовок Location для автоматического перенаправления к предложенному ресурсу. Этот запрос может быть закэширован, если явно не было указано иного.

301 (Moved Permanently — Перемещено навсегда)

Код перенаправления. Указывает, что модель ресурсов REST API была сильно изменена и теперь имеет новый URL. Rest API должен указать новый URI в заголовке ответа Location, и все будущие запросы должны быть направлены на указанный URI.

Вы вряд ли будете использовать этот код ответа в своем API, так как вы всегда можете использовать версию API для нового API, сохраняя при этом старый.

302 (Found — Найдено)

Является распространенным способом выполнить перенаправление на другой URL. HTTP-ответ с этим кодом должен дополнительно предоставит URL-адрес куда перенаправлять в поле заголовка Location. Агенту пользователя (например, браузеру) предлагается в ответе с этим кодом сделать второй запрос на новый URL.

Многие браузеры реализовали этот код таким образом, что нарушили стандарт. Они начали изменять Тип исходного запроса, например с POST на GET. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.

303 (See Other — Смотрите другое)

Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки нежелательного тела ответа он отправляет клиенту URI ресурса. Это может быть URI временного сообщения о состоянии ресурса или URI для уже существующего постоянного ресурса.

Код состояния 303 позволяет REST API указать ссылку на ресурс, не заставляя клиента загружать ответ. Вместо этого клиент может отправить GET запрос на URL указанный в заголовке Location.

Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.

304 * (Not Modified — Не изменен)

Этот код состояния похож на 204 (Нет контента), так как тело ответа должно быть пустым. Ключевое различие состоит в том, что 204 используется, когда нет ничего для отправки в теле, тогда как 304 используется, когда ресурс не был изменен с версии, указанной заголовками запроса If-Modified-Since или If-None-Match.

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

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

305 — (Use Proxy — Используйте прокси)

Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси-сервер, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерироваться ТОЛЬКО серверами-источниками.

Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.

Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.

307 (Temporary Redirect — Временный редирект)

Ответ 307 указывает, что rest API не будет обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URL, указанный в заголовке Location. Однако в будущих запросах клиент по-прежнему должен использоваться исходный URL.

Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.

Если метод запроса не HEAD, тело ответа должно содержать короткую заметку с гиперссылкой на новый URL. Если код 307 был получен в ответ на запрос, отличный от GET или HEAD, Клиент не должен автоматически перенаправлять запрос, если он не может быть подтвержден Клиентом, так как это может изменить условия, при которых был создан запрос.

308 — (Permanent Redirect — Постоянное перенаправление) (experimental)

Нужно повторить запрос на другой адрес без изменения применяемого метода.

Этот и все последующие запросы нужно повторить на другой URI. 307 и 308 (как предложено) Схож в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на «постоянно перенаправленный» ресурс можно продолжать без проблем.

400 * (Bad Request — Плохой запрос)

Это общий статус ошибки на стороне Клиента. Используется, когда никакой другой код ошибки 4xx не уместен. Ошибки могут быть как неправильный синтаксис запроса, неверные параметры запроса, запросы вводящие в заблуждение или маршрутизатор и т.д.

Клиент не должен повторять точно такой же запрос.

401 * (Unauthorized — Неавторизован)

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

Клиент может повторить запрос указав в заголовке подходящее поле авторизации. Если это уже было сделано, то в ответе 401 будет указано, что авторизация для указанных учетных данных не работает. Если в ответе 401 содержится та же проблема, что и в предыдущем ответе, и Клиент уже предпринял хотя бы одну попытку проверки подлинности, то пользователю Клиента следует представить данные полученные в ответе, владельцу сайта, так как они могут помочь в диагностике проблемы.

402 — (Payment Required — Требуется оплата)

Этот код зарезервирован для использования в будущем.

Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 * (Forbidden — Запрещено)

Ошибка 403 указывает, что rest API отказывается выполнять запрос клиента, т.е. Клиент не имеет необходимых разрешений для доступа. Ответ 403 не является случаем, когда нужна авторизация (для ошибки авторизации используется код 401).

Попытка аутентификация не поможет, и повторные запросы не имеют смысла.

404 * (Not Found — Не найдено)

Указывает, что rest API не может сопоставить URL клиента с ресурсом, но этот URL может быть доступен в будущем. Последующие запросы клиента допустимы.

404 не указывает, является ли состояние временным или постоянным. Для указания постоянного состояния используется код 410 (Gone — Пропал). 410 использоваться, если сервер знает, что старый ресурс постоянно недоступен и более не имеет адреса.

405 (Method Not Allowed — Метод не разрешен)

API выдает ошибку 405, когда клиент пытался использовать HTTP метод, который недопустим для ресурса. Например, указан метод PUT, но такого метода у ресурса нет.

Ответ 405 должен включать Заголовок Allow, в котором перечислены поддерживаемые HTTP методы, например, Allow: GET, POST.

406 (Not Acceptable — Неприемлемый)

API не может генерировать предпочитаемые клиентом типы данных, которые указаны в заголовке запроса Accept. Например, запрос клиента на данные в формате application/xml получит ответ 406, если API умеет отдавать данные только в формате application/json.

В таких случаях Клиент должен решить проблему данных у себя и только потом отправлять запросы повторно.

407 — (Proxy Authentication Required — Требуется прокси-аутентификация)

Ответ аналогичен коду 401, за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

Пользователь должен сначала авторизоваться через прокси. Прокси-сервер должен вернуть Proxy-Authenticate заголовок, содержащий запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком. Появился в HTTP/1.1.

408 — (Request Timeout — Таймаут запроса)

Время ожидания сервером передачи от клиента истекло. Клиент не предоставил запрос за то время, пока сервер был готов его принят. Клиент МОЖЕТ повторить запрос без изменений в любое время.

Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос.

409 * (Conflict — Конфликт)

Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должен содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако это не всегда возможно и это не обязательно.

Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.

410 — (Gone — Исчез)

Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411 — (Length Required — Требуется длина)

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение.

412 — (Precondition Failed — Предварительное условие не выполнено)

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

Когда клиент указывает rest API выполнять запрос только при выполнении определенных условий, а API не может выполнить запрос при таких условиях, то возвращается ответ 412.

Этот код ответа позволяет клиенту записывать предварительные условия в метаинформации текущего ресурса, таким образом, предотвращая применение запрошенного метода к ресурсу, кроме того, что ожидается.

413 — (Request Entity Too Large — Сущность запроса слишком большая)

Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса.

Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

414 — (Request-URI Too Long — Запрос-URI Слишком длинный)

Сервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в «чёрную дыру» перенаправлений (например, когда префикс URI указывает на своё же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длиной буфера для чтения или обработки Request-URI.

415 (Unsupported Media Type — Неподдерживаемый медиа тип)

Сообщение об ошибке 415 указывает, что API не может обработать предоставленный клиентом Тип медиа, как указано в заголовке запроса Content-Type.

Например, запрос клиента содержит данные в формате application/xml, а API готов обработать только application/json. В этом случае клиент получит ответ 415.

Например, клиент загружает изображение как image/svg+xml, но сервер требует, чтобы изображения использовали другой формат.

428 — (Precondition Required — Требуется предварительное условие)

Код состояния 428 указывает, что исходный сервер требует, чтобы запрос был условным.

Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.

Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.

429 — (Too Many Requests — Слишком много запросов)

Пользователь отправил слишком много запросов за заданный промежуток времени.

Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.

431 — (Request Header Fields Too Large — Слишком большие поля заголовка запроса)

Код состояния 431 указывает на то, что сервер не желает обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен повторно после уменьшения размера полей заголовка запроса.

Его можно использовать как в случае, когда совокупность полей заголовка запроса слишком велика, так и в случае неисправности одного поля заголовка. В последнем случае представление ответа ДОЛЖНО указывать, какое поле заголовка было слишком большим.

444 — (No Response — Нет ответа) (Nginx)

Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)

451 — (Unavailable For Legal Reasons — Недоступен по юридическим причинам)

Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующих является код 403 Forbidden (сервер понял запрос, но отказывается его обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено несколько вариантов для нового кода, включая «112 Emergency. Censorship in action» и «460 Blocked by Repressive Regime»

500 * (Internal Server Error — Внутренняя ошибка сервера)

Общий ответ при ошибке в коде. Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

Большинство веб-платформ автоматически отвечают этим кодом состояния, когда при выполнении кода обработчика запроса возникла ошибка.

Ошибка 500 никогда не зависит от клиента, поэтому для клиента разумно повторить точно такой же запрос, и надеяться что в этот раз сервер отработает без ошибок.

501 (Not Implemented — Не реализован)

Серверу либо неизвестен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).

Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.

502 — (Bad Gateway — Плохой шлюз)

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился. Появился в HTTP/1.0.

503 — (Service Unavailable — Служба недоступна)

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время известно, то его МОЖНО передать в заголовке Retry-After.

504 — (Gateway Timeout — Таймаут шлюза)

Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.

505 — (HTTP Version Not Supported — Версия HTTP не поддерживается)

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

510 — (Not Extended — Не расширен)

В запросе не соблюдена политика доступа к ресурсу. Сервер должен отправить обратно всю информацию, необходимую клиенту для отправки расширенного запроса. Указание того, как расширения информируют клиента, выходит за рамки данной спецификации.

—

Источники и более подробная информация:

  • https://restapitutorial.ru/httpstatuscodes.html
  • https://www.restapitutorial.com/httpstatuscodes.html
  • https://restfulapi.net/http-status-codes/
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428

Как проверить правильные ли коды отдает хостинг (200, 404 и т.д.), настроена ли 404-я страница

04.07.2014.

Перед продвижением сайта важно убедиться, корректно ли работает сервер, на котором расположен сайт, правильные ли коды ответа он отдает. Кодов ответа существует довольно много, нам же, для начальной проверки правильности работы, нужно проверить основные 2 кода:

  • 200
  • 404

Код ответа 200 — «OK» — означает, что всё хорошо, страница существует и выдана сервером.

Код 404 говорит о том, что запрошенной страницы не существует.

Почему важно, что бы сервер отдавал правильные коды?

Если сервер будет отвечать не правильными кодами, то могут возникнуть проблемы с индексацией сайта поисковыми системами, а это значит — что ваш сайт не посетит множество потенциальных клиентов.

Как проверить код 200?

О проверке кодов ответа мы уже писали тут, вкратце — используем этот сервис (пункт «Заголовки»):

Или задаем в любой поисковой системе запрос типа «проверить ответы сервера», переходим на сайт, вбиваем существующий адрес страницы вашего сайта (рекомендуем проверять главную и ещё пару адресов) и получаем код ответа сервера (строка, содержащая HTTP/** (код)). Если на всех проверенных страницах код 200 OK — значит всё работает правильно, если нет — даем задание администратору исправить это.

Как проверить код 404?

Код ответа 404 проверяется аналогично 200-му, только для проверки нужно использовать адрес не существующей на сайте страницы (например, случайную комбинацию букс и цифр — https://realyseo. ru/dfghghf1425ff). Если в кодах ответа указано 404, то сервер отдает правильный код, если что-то иное — даем задание администратору починить сервер.

Теперь переходим к 404-й странице.

Что такое 404-я страница, почему она важна, как её проверить?

404-я страница говорит посетителю сайта о том, что такого документа на сайте не существует. Пользователь может попасть на такую страницу разными способами:

  • Не правильно набрать адрес существующей страницы
  • Перейти по ссылке со стороннего сайта или поисковика на удаленную страницу
  • Перейти по ссылке с опечаткой в адресе
  • И тому подобное

По умолчанию, многие web серверы, хостинги и CMS используют крайне не информативную страницу 404-ю страницу, попав на которую посетитель, скорее всего, навсегда уйдет с вашего сайта:

Такая страница не содержит навигации, поиска по сайту и т.п. Фактически, пользователь даже не понимает, какому сайту она принадлежит. То есть посетитель, попавший на такую или подобную страницу, для вас потерян навсегда.

Для того, что бы избежать потери потенциального клиента, попавшего на не существующую страницу, нужно оформить 404-ю страницу. Для начала, проверьте, как она отображается у вас на сайте, использовав вымышленный url адрес (например,  https://realyseo.ru/dfghghf1425ff ) — если это страница, похожая на скриншот выше, то обязательно нужно её изменить.

Как изменить 404-ю страницу?

Для того, что показывать свою страницу ошибки 404, нужно добавить в файл .htaccess в корневой папке сайта (если такого файла нет, то его нужно создать) строку:

ErrorDocument 404 /404.html

Где  «404.html » — относительный адрес страницы, которая будет выдаваться при коде ответа 404.

Что нужно разместить на 404-й странице?

Важно, что бы посетитель, попавший на не существующую страницу, сразу понял, где он оказался. На хорошей 404-й странице должны быть:

  • Логотип и название сайта (желательно, являющиеся ссылкой на главную)
  • Главное меню
  • Сообщение о том, что такой странице нет на сайте (на видном месте, желательно, крупно)
  • Форма поиска по сайту
  • Контакты или ссылка на контакты
  • Счетчики статистики (для дальнейшего выявления, откуда посетители попадают на эту страницу)

Если всё вышеперечисленное будет на вашей 404-й странице, то, с большой долей вероятности, посетитель не покинет сайт сразу (как в 404 страницей по-умолчанию), а воспользуется им.

Оформить 404-ю страницу можно как в общем стиле сайта, так и в собственном стиле, главное — соблюдать рекомендации по содержанию, приведенные выше.

Понравилась статься? Подпишитесь на обновления:

kubernetes — вход nginx с letsencrypt: ожидание распространения запроса http-01: неправильный код состояния «404», ожидаемый «200»

Я пытаюсь выполнить повторное развертывание с GKE на Digital Ocean. У меня возникла проблема с вызовом от letsencrypt. Я считаю, что K8s говорит мне, что маршрут не может быть найден. Два имени хоста/домена, которые letsencrypt пытается выполнить, но терпит неудачу, — это CNAMES, используемые SendGrid. Я не совсем уверен, с чего начать устранение неполадок, мой google-fu подводит меня.

 Пространство имен: по умолчанию
Ярлыки: <нет>
Аннотации: <нет>
Версия API: acme.cert-manager.io/v1alpha2
Вид: Вызов
Метаданные:
  Отметка времени создания: 2020-03-19T20:34:04Z
  Финализаторы:
    finalizer.acme.cert-manager. io
  Поколение: 1
  Рекомендации владельца:
    Версия API: acme.cert-manager.io/v1alpha2
    Удаление владельца блока: правда
    Контроллер: правда
    Вид: Заказ
    Имя: letsencrypt-certs-80407504-346698183
    UID: 84ab9399-3a61-462e-a1c5-0831bd451a36
  Версия ресурса: 37060
  Самостоятельная ссылка: /apis/acme.cert-manager.io/v1alpha2/namespaces/default/challenges/letsencrypt-certs-80407504-346698183-813483524
  UID: ca14d996-3ecf-4dd8-8c53-057af7ae2b27
Спецификация:
  URL-адрес аутентификации: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3449670327
  DNS-имя: 7502121.secodify.com
  Исх. эмитента:
    Группа: cert-manager.io
    Тип: ClusterIssuer
    Название: letsencrypt-prod
  Ключ: LiAawBR0bFRQfb2oXrvvNhph4ehQ-35lXJKkpjqgqb0.uWh5RnJfcABYba9T5b-QjoYnIw53rRTVhzsRIHIh49Y
  Решатель:
    http01:
      Вход:
        Класс: nginx
  Токен: LiAawBR0bFRQfb2oXrvvNhph4ehQ-35lXJKkpjqgqb0
  Тип: http-01
  URL-адрес: https://acme-v02.api.letsencrypt.org/acme/chall-v3/3449670327/JGayWw
  Подстановочный знак: ложь
Положение дел:
  Представлено: правда
  Обработка: правда
  Причина: ожидание распространения запроса http-01: неправильный код состояния «404», ожидаемый «200»
  Состояние: в ожидании
События: <нет>

моя карта конфигурации выглядит так: 9~ /. well-known/acme-challenge/ { default_type «текстовый/обычный»; переписать /.well-known/acme-challenge/(.*) /$1 break; } местоположение /статическое/ { включен автоиндекс; псевдоним /code/core/static/; включить /etc/nginx/mime.types; } местоположение = /favicon.ico { доступ_лог выключен; log_not_found выключен; } расположение / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $ схема; прокси_пароль http://127.0.0.1:8080/; } } } —«` 9~ /.well-known/acme-challenge/

Не забудьте также добавить аннотации класса rewrite и nginx в файл конфигурации Ingress.

Оказывается, CNAMES не использовались. После удаления их из конфига я бы снова сделал kubectl get challenge , но он был пуст. Я предполагаю, что это потому, что вызовы уже были обработаны, и, следовательно, не было ожидающих решения.

У меня также была другая проблема, когда я забыл установить связь между службой kubernetes и модулями развертывания.

Между двумя вопросами я запутался.

У меня была такая же ошибка на K3S с Traefik. Причиной тому был DNS и перенаправление портов. Certmanager тестирует себя, прежде чем обращаться к Letsencrypt. Я бы получил ту же ошибку, если бы использовал Nginx в качестве маршрутизатора.

У меня есть:

  • Raspberry Pi
  • работает с Kubernetes
  • в моем «ДМЗ»
  • Доступ предоставляется с помощью переадресации портов на порт 80/443 на моем маршрутизаторе.

Я установил несколько записей A в DNS-сервере провайдера моих доменов:

  • Внешне https://mypi.example.com разрешается моему маршрутизатору и через переадресацию портов, обслуживаемых моим Raspberry Pi.
  • В моем DMS https://mypi.exampe.com по-прежнему обслуживал веб-сайт администратора моего маршрутизатора

Certmanager звонит моему маршрутизатору, чтобы проверить его функциональность Letsencrypt вместо себя на Raspberry Pi.

Проблема решается добавлением DNS-записей на DNS-сервер моего роутера для доменов, чтобы они напрямую указывали на внутренний IP-адрес Raspberry Pi.

Конечно:

  • Моя «демилитаризованная зона» должна быть более защищенной, а веб-сайт администратора маршрутизатора и внутренняя сеть не должны быть доступны с Raspberry Pi
  • Мой Raspbery Pi не должен инициировать подключения к Интернету, за исключением обновлений.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

nginx ingress — распространение вызовов Kubernetes Letsencrypt Cert-Manager Acme http-01: неправильный код состояния «404», ожидаемый «200»

в настоящее время я настраиваю кластер Kubernetes с голым металлом, содержащий два узла с metallb в качестве балансировщика нагрузки.
Вход, который я использую, это nginx, который также настраивается через helm: «`helm install nginx nginx/nginx«`
Я устанавливаю cert-manager через helm: «`helm install cert-manager jetstack/cert-manager -n cert -manager«`

Чтобы заставить работать https, я следовал инструкциям [cert-manager][1].
К сожалению, выполнение этих инструкций не работает, потому что я получаю сообщение об ошибке: «Ожидание распространения запроса HTTP-01: неправильный код состояния «404», ожидается «200» при развертывании kuard.

Завиток к поду acme через IP возвращает 200 с токеном:

 curl -I -H "Host: example.mydns.dev" 10.96.151.217:8089/.well-known/acme-challenge/ aDEelPosRNx9HoA3QkTOPRNbWCK8UjOkszdtCh7Wogw
HTTP/1.1 200 ОК
Cache-Control: без кэша, без хранения, с обязательной повторной проверкой
Дата: пятница, 07 октября 2022 г., 16:42:44 по Гринвичу
Длина контента: 87
Content-Type: текстовый/обычный; кодировка = utf-8

Завиток к поду через DNS возвращает 308:

 ❯ curl -I -H "Хост: example. mydns.dev" example.mydns.dev/.well-known/acme-challenge/aDEelPosRNx9HoA3QkTOPRNbWCK8UjOkszdtCh7Wogw
HTTP/1.1 308 Постоянное перенаправление
Расположение: https://example.mydns.dev/.well-known/acme-challenge/aDEelPosRNx9HoA3QkTOPRNbWCK8UjOkszdtCh7Wogw
Дата: пятница, 07 октября 2022 г., 16:43:46 по Гринвичу
Длина содержимого: 18
Content-Type: текстовый/обычный; кодировка = utf-8

Я предполагаю, что в ingress nginx есть неправильная конфигурация. Это какой-то консольный вывод:

 ❯ kubectl получить вход
НАЗВАНИЕ КЛАСС ХОСТИ АДРЕС ПОРТЫ ВОЗРАСТ
cm-acme-http-solver-2j9p5 <нет> example.mydns.dev 192.168.69.0 80 13 м
kuard <нет> example.mydns.dev 192.168.69.0 80, 443 13 м
kubectl описать вход
Имя: cm-acme-http-solver-2j9p5
Ярлыки: acme.cert-manager.io/http-domain=1704593603
                  acme.cert-manager.io/http-токен=1120145148
                  acme.cert-manager.io/http01-solver=true
Пространство имен: по умолчанию
Адрес: 192.168.69.0
Класс входа: 
Серверная часть по умолчанию: <по умолчанию>
Правила:
  Серверные части пути к хосту
  ---- ---- --------
  пример. mydns.dev
                          /.well-known/acme-challenge/aDEelPosRNx9HoA3QkTOPRNbWCK8UjOkszdtCh7Wogw cm-acme-http-solver-x6659:8089 (10.44.0.3:8089)
Аннотации: kubernetes.io/ingress.class: nginx
                          nginx.ingress.kubernetes.io/whitelist-source-range: 0.0.0.0/0,::/0
События:
  Тип Причина Возраст от сообщения
  ---- ------ ---- ---- -------
  Обычная синхронизация 13 м (x2 более 13 м) nginx-ingress-controller Синхронизация по расписанию
Имя: куард
Ярлыки: <нет>
Пространство имен: по умолчанию
Адрес: 192.168.69.0
Класс входа: 
Серверная часть по умолчанию: <по умолчанию>
TLS:
  example-tls завершает работу с example.mydns.dev
Правила:
  Серверные части пути к хосту
  ---- ---- --------
  пример.mydns.dev
                          / куард:80 (10.32.0.7:8080)
Аннотации: cert-manager.io/cluster-issuer: letsencrypt-staging
                          kubernetes.io/ingress.class: nginx
События:
  Тип Причина Возраст от сообщения
  ---- ------ ---- ---- -------
  Обычный CreateCertificate 13m cert-manager-ingress-shim Успешно создан сертификат "example-tls"
  Обычная синхронизация 13 м (x2 более 13 м) nginx-ingress-controller Синхронизация по расписанию

Вот файлы, которые я использовал:

ClusterIssuer:

 apiVersion: cert-manager. io/v1
вид: ClusterIssuer
метаданные:
  имя: letsencrypt-staging
спецификация:
  акме:
    # URL-адрес сервера ACME
    сервер: https://acme-staging-v02.api.letsencrypt.org/directory
    # Адрес электронной почты, используемый для регистрации ACME
    электронная почта: [email protected]
    # Имя секрета, используемого для хранения закрытого ключа учетной записи ACME
    privateKeySecretRef:
      имя: letsencrypt-staging
    # Включить поставщика вызовов HTTP-01
    решатели:
    - http01:
        вход:
          класс: nginx

Kuard Ingress:

 apiVersion: networking.k8s.io/v1
вид: Вход
метаданные:
  имя: куард
  аннотации:
    kubernetes.io/ingress.class: «nginx»
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
спецификация:
  тлс:
  - хозяева:
    - пример.mydns.dev
    secretName: пример-TLS
  правила:
  - хост: example.mydns.dev
    http:
      пути:
      - путь: /
        тип пути: префикс
        серверная часть:
          услуга:
            имя: куард
            порт:
              номер: 80

Вот некоторые результаты отладки:

 ❯ kubectl получить сертификат
ИМЯ ГОТОВ ТАЙНЫЙ ВОЗРАСТ
пример-tls Ложный пример-tls 2m19s
❯ kubectl получить заказы -o широкий
ИМЯ ГОСУДАРСТВО ЭМИДЕНТ ПРИЧИНА ВОЗРАСТ
пример-tls-42np9-1759938310 в ожидании letsencrypt-staging 2m22s
❯ kubectl получить вызов -o широкий
ИМЯ СОСТОЯНИЕ ДОМЕН ПРИЧИНА ВОЗРАСТ
пример-tls-42np9-1759938310-206991323 pending example.
No related posts.