Содержание

Сервер отвечает http кодом 404. Полное руководство по кодам статуса HTTP. HTTP заголовки и их значение

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Код ответа 200 — один из типов кодов HTTP, информирует пользователя об успешной обработке запроса. Исходя из статуса, сервер может предоставлять тело и заголовок сообщения.

Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA

Приведем пример. Вы отправили посылку в другой город. На почте вам выдали трек-номер для отслеживания. По нему вы смотрите, что с вашим отправлением — вот оно покинуло сортировочный центр вашего города, вот прибыло в другой. Вот его вручили адресату. Каждый раз система выдает вам статус в ответ на запрос.



Как это работает

Для начала разберем . Итак, пользователь открывает браузер и делает запрос к интернет-ресурсу. После этого браузер получает ответ хоста, где и указан код из трех цифр. По комбинации цифр можно определить, какая ситуация сейчас наблюдается на хосте.

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

Что означает код 200 для правильной индексации сайта

Категория серверных ответов 2хх является категорией «Success». Эта категория уведомляет пользователей о положительном результате. В частности, код “200 ОК” говорит пользователю, что его запрос успешно выполнен. Например, клиент запросил те или иные данные. Ответ сервера 200 означает, что эти данные отображены в заголовке или сообщении.

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

Важно проверить, не отдают ли несуществующие страницы код 200. Это возможно даже когда визуально вы видите на экране “404 — страница не найдена”. Причиной этой проблемы может стать неправильная настройка работы сайта. Если вы не хотите проблем с продвижением вашего ресурса — проверьте все типы страниц на корректный ответ сервера. Так вы сможете выявить страницы, которые только прикидываются нужными.


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

Для этого вы можете воспользоваться одной из множества программ, которые есть в интернете. Какие-то делают массовые проверки для всех страниц сайта, какие то требуют ввода каждого URL. Выбирайте сервис исходя из ваших задач.

На самом деле кодов ответа сервера большое количество, но самые часто встречающиеся следующие:

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

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

452

Коды статуса и ошибок HTTP похожи на короткое сообщение от сервера, которое выводится в верхней части веб-страницы. На самом деле это не часть веб-страницы. Это сообщение, возвращаемое при обращении к серверу, позволяет узнать, как обстояли дела, когда сервером был получен запрос на просмотр страницы.

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

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

В этой статье представлены наиболее распространенные коды статуса и коды ошибок.

Откуда они берутся?

Каждый раз, когда вы кликаете по ссылке или вводите URL-адрес и нажимаете «Enter », браузер отправляет запрос на сервер. Он получает и обрабатывает запрос, а затем отправляет обратно запрашиваемые ресурсы вместе с HTTP-заголовком .

Коды статуса доставляются в браузер в HTTP-заголовке . Хотя вы их не видите. Но когда что-то пошло не так, пользователю отображается код статуса в браузере. Это способ сервера сказать: «Что-то не так. Вот код, который объясняет, что именно ».

Код статуса HTTP Google 404

Чтобы увидеть коды статуса, которые браузер обычно не отображает, потребуются специальные инструменты. Для популярных браузеров, таких как Chrome и Firefox , доступны соответствующие расширения. Также существует много сервисов для отображения заголовков, например Web Sniffer .

Чтобы увидеть код статуса HTTP с помощью одного из этих инструментов, найдите строку, расположенную в верхней части отчета, в которой указано: “Status: HTTP/1.1 ”. После нее указан код статуса, возвращаемый сервером.

Классы кодов статуса HTTP

Коды статуса HTTP разделены на 5 классов:

  • 100: информационные коды, указывающие, что запрос, инициированный браузером, продолжается.
  • 200: коды успешного запроса. Возвращаются, когда запрос браузера был успешно получен, распознан и обработан сервером.
  • 300: коды перенаправления возвращаются, когда запрошенный ресурс заменен новым.
  • 400: http-ошибки , возникающие на стороне клиента и указывающие на наличие проблемы с запросом.
  • 500: коды ошибок сервера, указывающие, что запрос был принят, но ошибка на сервере не позволила выполнить его.

Список кодов статуса HTTP

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

Ниже приводится список кодов статуса HTTP :

Код статуса 200

200: «Все в порядке ». Это код, который возвращается, когда веб-страница или ресурс действуют точно так, как ожидается.

Коды статуса 300

301: «Запрошенный ресурс был перемещен навсегда ». Этот код возвращается, когда веб-страница или ресурс заменяется другим ресурсом. Он используется для постоянного редиректа URL-адресов .

302: это http-ошибка «Запрошенный ресурс перемещен, но был найден ». Этот код используется для указания того, что запрошенный ресурс был найден, но не в том месте, где это ожидалось. Он используется для временного редиректа URL-адресов .

304: «Запрошенный ресурс не был изменен с момента последнего обращения к нему ». Сообщает, что ресурсы, хранящиеся в кэше браузера, не изменились. Он используется для ускорения доставки веб-страниц за счет повторного использования ранее загруженных ресурсов.

Коды статуса 400

http-ошибка 403: «Доступ к этому ресурсу запрещен ». Возвращается, когда пользователь пытается открыть ресурс, для которого у него нет прав доступа. Например, попытка просмотра неавторизованным пользователем контента, защищенного паролем, может привести к ошибке 403 .

404: «Запрошенный ресурс не найден ». Наиболее распространенное сообщение об ошибке. Означает, что запрошенный ресурс не существует и сервер не знает, существовал ли он когда-либо.

405: «Метод не разрешен ». Генерируется, когда хостинг-сервер (исходный сервер ) поддерживает полученный метод, но целевой ресурс отсутствует.

406: «Неприемлемый ответ ». Запрошенный ресурс способен генерировать только контент, неприемлемый в соответствии с заголовками Accept , отправленными в запросе.

408: «Время ожидания сервером поступления остальной части запроса из браузера истекло ». Генерируется, когда сервер прерывает обработку после истечения времени ожидания полного запроса от браузера. Другими словами, сервер не получил полный запрос, отправленный браузером.

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

410: «Запрошенный ресурс отсутствует и не будет возвращен ». Подобен коду 404 «Не найден », за исключением того, что код статуса 410 , указывает, что данный статус ожидается на постоянной основе.

429: это http-ошибка «Слишком много запросов ». Генерируется сервером, когда пользователь отправил слишком много запросов в заданный промежуток времени (ограничение по скорости ). Иногда причиной ошибки могут быть боты, пытающиеся получить доступ к сайту. В этом случае может потребоваться изменение URL-адреса входа в панель администрирования WordPress .

429 слишком много запросов

499: «Клиент закрыл запрос ». Возвращается NGINX , когда клиент закрывает запрос, пока NGINX все еще обрабатывает его.

Коды статуса500

500: «На сервере возникла ошибка, и запрос не мог быть завершен ». Общий http-код , который также называют «внутренняя ошибка сервера ». На сервере что-то пошло не так и запрошенный ресурс не был доставлен. Этот код генерируется сторонними плагинами, при сбоях PHP-кода или подключения к базе данных.

Ошибка при установлении соединения с базой данных

501: «Не реализовано ». Эта ошибка указывает на то, что сервер не поддерживает функции, необходимые для выполнения запроса. Ошибка почти всегда связана с самим сервером, и для ее решения нужно обратиться в службу поддержки хостинг-провайдера.

Здравствуйте, уважаемые читатели блога сайт. Сегодня я хочу рассмотреть коды состояния и HTTP заголовки, входящие в качестве составных частей в ответ сервера и дающие ценную информацию о работе сайта. Ну и разберем, какие инструменты позволяют их проверить.

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

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

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

Ответ сервера и его составляющие, которые могут повлиять на SEO

В статье, объясняющей суть передачи данных посредством протокола HTTP (HTTPS), ссылка на которую дана в начале публикации, я писал о том, как в принципе происходит общение , которое основывается на схеме «запрос клиента — ответ сервера»

.

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

Получив нужный IP, браузер посылает на соответствующий этому ай-пи сервер запрос GET для получения нужного содержания. Серверное ПО обрабатывает запрос и высылает ответ, включающий содержание вебстраницы в виде HTML-кода, который затем модифицируется веббраузером для отображения контента странички в удобоваримом виде.

Но, как говорится, не браузером единым…Аналогичным образом с сервером может «вести диалог» любая клиентская программа, которая снабжена необходимым для этого функционалом, в том числе роботы поисковых систем . Принципы механизма подобного взаимодействия для различных приложений абсолютно тождественны, разница лишь в деталях.

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

Чтобы практически осуществить проверку ответа сервера на запрос робота поисковой системы Яндекс, можно воспользоваться специальным инструментом , где вводите URL исследуемой страницы, а также выбираете нужного бота из выпадающего списка (кроме основного там присутствуют роботы по зеркалам, по картинкам, по поиску видео и другие):


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

HTTP коды состояния — 200, 301, 302, 403, 404, 500 и другие

Код состояния, приходящий в ответе сервера, определяет статус вебстраницы сайта, в отношении которой клиентское приложение отправляет запрос на сервер. Например, HTTP 200 OK означает, что все все содержимое странички передано и будет доступно для просмотра.

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


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

1. 1XX — информационные, в которых сервер сообщает о процессе обработки запроса.


2. 2XX — HTTP коды, информирующие об успешно переданных данных. О 200 OK я уже упомянул, остальные являются его производными.


3. 3XX — переадресация различного вида с одного URL на другой. Например, если 301 означает, что адрес страницы изменен навсегда, то код 302 говорит о временном перенаправлении. В отличие от постоянного 302 редирект не является сигналом поисковым системам для передачи веса страницы со старого адреса, поэтому на практике он используется лишь в исключительных ситуациях, когда является наиболее оптимальным решением.


4. 4XX — HTTP коды ошибок в запросе со стороны клиента. Например, всем известный код статуса 404 означает, что документа по такому адресу на хосте нет.


5. 5XX — ошибка на сервере, в результате которой страница не может быть предоставлена.


Более подробный список кодов состояния, предоставляемых в HTTP ответе сервера, вы можете получить, если посетите соответствующую страницу Википедии .

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

Бывали случаи, например, когда сервер отвечает HTTP кодом 404 вместо ожидаемого 200 , поскольку в реальности вебстраницы доступны и прекрасно открываются. Если такая ситуация, не дай бог, сложится при ответе сервера на запрос того же робота Яндекса, то вполне вероятно, произойдет выпадение этих страниц из индекса, что будет очень обидно.

Но если даже подобный форс-мажор произойдет, своевременная проверка кода состояния поможет вовремя обнаружить эту неприятность и исправить ее последствия с минимальными затратами времени и сил, которые могут вам понадобиться для других важных дел по оптимизации сайта.

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

Если взгляните на скриншот выше, где дан ответ сервера, то увидите, что чуть ниже строки с кодом статуса присутствует пояснение, включающее информацию о времени ответа сервера, IP-адресе сайта, кодировке и размере страницы:

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

Какой же должна быть величина времени отклика? Гугл, например, определяет максимальную границу в 200 мс (миллисекунд), но, конечно, чем меньше, тем лучше. Как же увеличить скорость ответа сервера? Для начала попробуйте провести некоторые мероприятия по , вполне возможно, что проблему решит установка плагина кеширования.

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

HTTP заголовки и их значение

В этом свете будем рассматривать примеры ответов на запросы роботов поисковых систем , поскольку они интересуют нас в первую очередь. Для наглядности вначале представляю скриншот с HTTP заголовками, соответствующими урлу страницы со статусом 200 ОК:


Server — название и версия веб-сервера. В данном примере это nginx, который в силу малого использования ресурсов и гибкости конфигурирования решает задачу оптимизации работы основного сервера Apache и используется с ним в связке.

Date — дата и время возврата содержания запрашиваемой страницы.

Content-Lenght — объем передаваемого контента в байтах ().

Connection — соединение. Параметр keep-alive означает, что после выдачи документа соединение с сервером не разрывается и можно отправлять дополнительные запросы.

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

Cache-Control — управление кешированием. В нашем образце этот заголовок отражает вид кеша, в котором располагается документ (public) и время, в течении которого он должен находиться в кеше (max-age). Значение public указывает, что эта операция применяется к файлам, хранящимся в общедоступном кэше. Параметр max-age выдает время в секундах.

X-Hyper-Cache — специальный заголовок, который многие пользователи WordPress, наверное, сразу идентифицировали. Несомненно, он касается работы , который я считаю, пожалуй, лучшим в своем классе. Значение «hit — gzip» показывает, что к кешированной странице применено сжатие методом gzip.

Content-Encoding — способ кодирования (в общем смысле) передаваемого в ответе содержания страницы. В нашем примере было применено сжатие gzip. Это сигнал клиентской программе (User Agent) распаковать содержимое для его корректного восприятия.

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

Content-Type — тип контента, который в этом примере представляет из себя HTML-код в кодировке UTF-8. Некорректное указание кодировки может привести к сложностям в восприятии текста пользователями и ботами ПС, а это чревато непопаданием страницы в индекс.

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

Last-Modified — дата последней модификации веб-страницы. Если клиент (в нашем случае робот Яндекса) получил от сервера этот заголовок с датой обновления контента, то при следующем обращении к URL этой же страницы он отправит серверу в составе запроса If-Modified-Since .

Вебсервер выделит промежуток от времени последних изменений до времени, указанного в заголовке If-Modified-Since. Ежели за этот период страница никоим образом не была изменена, то сервер отправит ответ с HTTP кодом 304 Not Modified , причем в этом случае содержание страницы отправлено не будет. Если же редактирование имело место, то робот получит код 200 ОК вместе с измененным контентом.

Этот механизм, если он настроен верно, позволяет выдавать постоянно свежую информацию. Ведь тут важна актуальность данных, что и обеспечивается правильной реализацией проверки времени последнего обновления. Ведь при неправильной настройке (если дата, указанная в Last-Modified не меняется) робот может получить просто код 304 Not Modified (вместо 200 OK с новой версией документа), хотя контент был несколько раз отредактирован.

Как же можно проверить корректность работы Last-Modified для сервера, на котором расположен ваш сайт? Попробуем разобраться на конкретном примере .

На том же сервисе Яндекса, ссылку на который я уже предложил выше, есть специальная опция, которая позволяет добавить запрос If-Modified-Since и указать нужные вам дату и время (в формате GMT, то есть по Гринвичу, относительно часового пояса Москвы это -3 часа) вплоть до минут, которое определит временной интервал проверки на обновление:


Взгляните на 10 скриншот вверх отсюда, где дан результат проверки в отношении урла одной из страниц моего блога (где отмечены все разделы ответа сервера). Там в части заголовков дано определенное значение Last-Modified, то есть дата последнего обновления. Теперь я включаю показатель If-Modified-Since в запрос и проверяю ответ сервера:


Как видите, получен код 304 Not Modified без содержания вебстраницы, что совершенно верно для данной ситуации, поскольку контент действительно не был обновлен за данный период. Далее для тестирования я добавил небольшой фрагмент текста в этой статье.

Затем я вновь послал запрос от робота Яндекса на сервер, который при правильно работающем механизме кэширования (после обновлении страницы в кеше присутствует последняя версия) должен возвратить ответ 200 ОК с новым содержанием, что и произошло:


Для полного успокоения можно еще просмотреть содержимое заголовка Content-Lenght, которое показывает, что объем контента незначительно, но увеличился (18443 против 18437 до редактирования). Это соответствует действительности, поскольку я именно добавил толику текста. Точно так же вы можете проверить правильность настройки заголовков для своего сервера.

Location — еще один заголовок, который я хотел бы отметить для полноты информации по этой теме. Он появляется в ответе сервера в том случае, ежели робот посылает запрос в отношении вебстраницы, с которой было совершено постоянное перенаправление (HTTP код 301):


Новый адрес, на который был проставлен редирект, и будет присутствовать в заголовке Location. Содержимое страницы в ответе отсутствует, что вполне логично, а вот в пояснении, которое следует за кодом ответа 301 Moved Permanently, указан размер страницы, на урл которой осуществляется переадресация.

Проверка ответа сервера в онлайн сервисах

Далее для полноты картины нелишним будет отметить online сервисы, которые позволяют проверить HTTP ответ сервера. На просторах интернета мне приглянулся вот этот (Checkmy.ru), который обладает достойным функционалом. Проверим теперь на нем отклик сервера, но уже на запрос робота Google для разнообразия:

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


Сервис Checkmy предлагает пользователям не только выбор приложения (User Agent), с которого будет отправлен запрос, но и использования заголовков If-Modified-Since и Accept-Encoding, о которых велась речь выше.

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

На сайте есть еще такая фишка как закладка для браузера, которая обеспечит скоростную проверку любой веб-страницы, на которую вы перейдете. Для этого достаточно прокрутить страницу вниз до нужного места, нажав на ссылку «Быстрый доступ» из верхнего меню. Затем, захватив левой кнопкой мышки кнопку «Checkmy» , переместить ее на панель закладок браузера:


В заключение отмечу еще сервис, с помощью инструмента которого удачно осуществите массовую проверку отклика сервера сразу для 200 URL, причем есть возможность загрузки архива ZIP с урлами. А на десерт видеролик о том, что такое код 404 Soft и чем он опасен для вебмастеров:

Невозможно без знания ответов сервера.

Пример:

404 Not found

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

На сегодняшний день выделено 5 основных классов кода ответа:

1xx: Informational (рус. Информационный) — запрос правильно воспринят, но его обработка не завершена.

2xx: Success (рус. Успешно) — запрос правильно воспринят и успешно обработан.

3xx: Redirection (рус. Перенаправление) — коды переадресации на другие страницы.

4xx: Client Error (рус. Ошибка клиента) — ошибка со стороны клиента.

5xx: Server Error (рус. Ошибка сервера) — ошибка со стороны сервера.

А теперь давайте по отдельности разберем некоторые коды состояния IANA.

Ответ сервера 1XX

100 Continue Server Code

100 Continue сообщает, что связь с сервером уже установлена, сервер принял корректный запрос и теперь ведется обмен данными между сервером и клиентом. Данный код является временным, т.е. за ним всегда следует другой. Код 100 является внутренним и не относится к ошибочным. Т.е. «дверь открыта, читай что нужно, как закончишь — закрой». Код 100 может и не генерироваться, если пользователь уже получил часть данных от сервера.

101 Switching Protocols

Данный код так же не является ошибочным. Генерируется при переключении с одного протокола на другой. Например, при запросе переключения со старой версии HTTP на более новую.

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

102 Processing

В каком-то смысле это аналог кода 100. Генерируется в том случае, когда обработка запроса может занять много времени. Для этих целей таймер ожидания сбрасывается и ожидание дальнейших команд происходит в обычном режиме. Так же не является кодом ошибки.

Ответ сервера 200 ОК

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

Ответ сервера 301

Также является одним из распространенных кодов ответа. Он сообщает, что запрашиваемая страница по данному адресу более не доступна, а затем происходит перенаправление на другой адрес. 301 редирект может применяться, например, при «переезде» сайта с протокола HTTP на HTTPS (обычно это реализуется через файл.htaccess, доступный на серверах Apache).

Ответ сервера 302

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

Ответ сервера 404

Вот уж что-что, а ошибку ответа сервера 404 не видели только те, кто еще не родился и те, кто умер до создания интернета. Данный код сообщает о том, что запрашиваемый документ по каким-то причинам на сайте отсутствует. Код ошибки ответа сервера 404 должен отдаваться только в том случае, если по указанному пользователем адресу документа никогда не было. Если документ ранее был доступен по этому адресу, а потом его удалили с сайта, то сервер должен отдавать код 410, а не 404.

Фейковые страницы 404

Большинство вебмастеров не обращает на 404-тые страницы никакого внимания, однако, это может серьезно навредить ранжированию сайта. Парадокс, но страница с сообщением 404 File Not Found далеко не всегда отдает код 404. Такие страницы принято называть «Soft 404». Причины возникновения просты — по каким-то причинам страница отдает код, отличный от 404 и 410 — например, 200. Такое вполне возможно, если страница уже создана, но контента на ней пока нет.

Ответ сервера 500

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

500 Internal Server Error

Код 500 отдается в случае любой внутренней ошибки сервера, за исключением остальных ошибок 5хх класса. Такая ошибка может быть отдана в том случае, когда ссылка генерируется на сервере непосредственно в момент запроса. Простейший пример — внутренний поиск по сайту: физически никакого документа по запрашиваемой ссылке нет.

Ответ сервера 502

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

Ответ сервера 550

При возникновении ошибки 550 необходимо проверить насколько корректно прописаны MX-записи, чтобы устранить данные ошибки ответа сервера.

На выходе будет представлена таблица.

Необходимо убедиться, что в ней прописаны необходимые записи для работы вашей почты:

ВАЖНО! Смешивание MX-записей недопустимо, т.е. в таблице на выдаче должны быть только те MX-записи, которые нужны именно для вашей почты . При необходимости нужно скорректировать записи, исправив ошибки и/или удалив лишнее.

Как получить коды ответа сервера (страницы) через Яндекс

Шаг 1. Проверяем код ответа сервера на страницу сайта, которая должна быть в поиске.

Открываем любую страницу Вашего сайта, находящуюся в поисковой выдаче Яндекса, затем из адресной строки копируем ее URL-адрес.

Теперь переходим в сервис Яндекса (http://webmaster.yandex.ru/server-response.xml), с помощью которого можно посмотреть на сайт глазами робота и проверить скорость ответа сервера в Яндекс панели.

Просто вставляем url-адрес интересующей нас страницы в текстовое поле и нажимаем на кнопку «Проверить». В данном случае мы получили код 200 ОК, свидетельствующий о нормальной работе страницы.

Шаг 2. Проверяем ответ сервера на заведомо несуществующую страницу.

В том же сервисе вводим имя_домена/какая-то_крокозябра

В данном случае мы получили ответ 301 Moved Permanently. Это говорит о том, что адрес страницы указан неверно и происходит переадресация на правильный адрес.

Как еще узнать коды ответа сервера (сайта)?

В качестве альтернативы можно пробить код ответа с помощью сервиса http://mainspy.ru . Работает аналогично сервису Яндекса: вставляем интересующий URL и жмем «Проверить». Код ответа в данном случае находится в самой первой строке:

Bertal, в отличие от Mainspy, позволяет взглянуть на страницу не только глазами Яндекс-бота, но и глазами поисковых роботов Bing и Google, а в качестве бонуса — может эмулировать популярные браузеры. Для удобства взглянем на те же страницы глазами GoogleBot. В данном случае код ответа подсвечен зеленым.

Массовая проверка ответов сервера (сайта) онлайн

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

Dimax.biz — http://backlinks-checker.dimax.biz/tools/proverka_otveta_servera.php — это один из лучших чекеров. Единственный минус — в бесплатном режиме можно делать не более 2 запросов по 50 ссылок каждый. Для более «серьезных» объемов придется воспользоваться платным PRO-тарифом. На выходе мы получаем список, отсортированных по коду ответа. В данном случае в сортировке нет необходимости, т.к. в списке всего 2 адреса, и оба отдают код 200.

Urlitor — еще один сервис, для массовой проверки кодов ответа. Сервис хорош тем, что результаты проверки сводятся в таблицу для облегчения восприятия. К слову — ссылки в таблице кликабельны.

Как проверить скорость (время) ответа сервера сайта?

Сколько таких сервисов уже развелось — не пересчитать. Рассмотрим некоторые из них.

Это англоязычный инструмент, анализирующий скорость по всем параметрам. С его помощью можно узнать скорость в секундах, сколько весит тестируемая страница, а также получить оценку и рекомендации для ее улучшения. Преимущество данного сервиса в том, что анализируется каждый отдельный элемент. Такой анализ позволяет выяснить, что именно затормаживает загрузку отдельно взятой страницы и/или сайта в целом.

Which Loads Faster

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

Google PageSpeed Insights

Google PageSpeed Insights так же является одним из самых мощных инструментов для измерения скорости работы мобильной и десктопной версии. Оценка производится по 100-бальной шкале. 85 баллов и более — это хороший показатель. Плюс бонусом он выдает рекомендации по улучшению.

Долгий ответ сервера

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

Сложная логика предоставления данных

Сервер не успевает своевременно обрабатывать поступающие запросы из-за их большого количества

Сами запросы (либо сложные, либо неоптимизированные, либо и то и другое)

Запросы к большому количеству внешних ресурсов

Большое количество исполняемых файлов

Сам веб-сервер долго обрабатывает запрос.

Самые «больные» места производительности сервера:

Используемый веб-сервер (Apache, IIS).

Ряд веб-серверов даже при выдаче статических файлов могут создавать задержки, т.к. они на архитектурном уровне не предназначены для обработки большого количества запросов и из-за этого может быть сообщения что превышено время ожидания ответа от сервера. Поэтому для нормальной работы веб-сервера имеет смысл использовать nginx (причем в связке с Apache, php-fpm, а также остальными серверами приложений для обработки серверных вычислений).

Использование OpCache.

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

Запросы к базе данных.

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

Сложная логика обработки данных.

Третий шаг — упрощение серверной логики. По сути, это просто устранение ненужных операций и профилирование времени выполнения серверных скриптов.

Обращение к сторонним сервисам.

Прописанные в коде серверных скриптов запросы к сторонним сервисам — это «обычная история», способная преподнести множество сюрпризов, поскольку производительность сервисов, откуда запрашиваются данные, практически никогда и никем не проверяется. А ведь время ответа стороннего сервиса напрямую влияет на время ответа сервера. Поэтому лучше всего в серверных запросах использовать только внутренние источники, которые в любой момент можно проконтролировать на качество производительности, либо в отложенном режиме запросить данные на клиентской.

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

Во-первых, потому что скорость загрузки является одним из факторов ранжирования (хоть и не решающим). Google открыто заявляет, что по скорости показа страниц ранжируется менее 1% сайтов. НО…

Во-вторых, если страница слишком долго грузится — пользователь ее просто закроет. Такое поведение пользователя принято называть «отказом». К слову, «отказы» оказывают прямое влияние на позиции в поисковой выдаче. Чем выше скорость загрузки — тем ниже процент отказов и, как следствие, тем выше позиции.

Превышено время ожидания ответа от сервера .

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

Основных же причин сбоя может несколько:

  • Невозможно подключиться к сайту из-за нестабильной работы его серверов;
  • Сбитые настройки браузера либо его захламленность;

    • Проблемы с подключением к интернету со стороны пользователя;

    Ресурс заблокирован.

Что делать для решения?

Если сбой единичен — перезагружаем страницу с помощью комбинации Ctrl+F5. Возможно, потребуется перезагрузить страницу несколько раз. Если не помогло — проверяем подключение к интернету.

Настройки Сети.

1. Некоторые сайты иногда «капризничают». Для динамического IP решение будет простым — перезагрузить роутер через отключение питания.

2. Медленное соединение иногда провоцирует ошибку ERR_CONNECTION_TIMED_OUT. Скорость работы интернета можно проверить через Яндекс-интернетометр . Если скорость слишком низкая — следует обратиться к интернет-провайдеру.

3. Необходимо проверить «Свойства сети» на наличие посторонних DNS-адресов. Если такие адреса имеются — удалить (предварительно на всякий случай переписав их куда-нибудь) и проверить систему на вирусы с помощью установленного на ПК антивирусного ПО — NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web и т.д. Лучше всего для этих целей использовать Live-загрузчики.

4. Проверить настройки самого роутера. Наиболее часто сбивается параметр MTU. Универсальных рекомендаций по настройке роутера дать невозможно, т.к. это напрямую зависит и от модели роутера, и от интернет-провайдера. Обычно MTU имеет значения 1500, 1460, 1476.

Какое должно быть время ответа сервера?

И сразу же конкретные цифры:

Самая высокая конверсия у страниц, которые полностью загружаются за 1,8 и 2,7 секунды для десктопной и мобильной версий соответственно

Самый низкий показатель отказов у страниц, которые полностью загружаются за 1 и 0.7 секунды для десктопной и мобильной версий соответственно

Данные цифры позаимствованы из исследования Akamai Technologies.

Итак, Вы проверили сайт на скорость загрузки. Но как реагировать на результаты?

    1-2 секунды — почти идеал

    3-5 секунд — сносно, но имеет смысл допилить

    5-10 секунд — плохо, нужно срочно допиливать

    ≥10 секунд — очень плохо, нужно ЭКСТРЕННО допиливать

Однако, нельзя забывать одно ультраважное правило — скорость загрузки должна быть выше, чем у конкурентов. Исследования The New York Times доказали, что разницы в 0,25 секунды может быть достаточно для того, чтоб посетители предпочли более быстрый сайт. И глазом моргнуть не успеете (в самом прямом смысле), как пользователь уйдет от Вас к конкуренту.

Сокращение ответа сервера

Оптимизация графики .

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

Использовать кеш браузера .

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

Включить сжатие .

Актуально, если используется gzip. В итоге объем данных сокращается раза в 4, а то и в 5. Чем меньше объем передаваемых данных — тем меньше времени занимает их передача.

Сократить время ответа сервера .

С помощью сервиса Pingdom можно вычислить, сколько времени требуется серверу для того, чтоб отдать код ответа. Идеальное время — не более 0,2 секунды.

Данные инструкции помогут значительно ускорить работу сайта. Однако, есть риск навредить функциональности или внешнему виду. Поэтому перед каждым действием в обязательном порядке делать бэкапы исходных файлов. Также не помешает проконсультироваться с техническими специалистами.

Страница 404 призвана сообщать пользователю, что заданный им url (адрес страницы) не существует.
Такие неправильные урлы еще можно назвать «битыми ссылками».
Многие сайты делают свои страницы 404 для удобства своих пользователей. Часто это красивые и интересные страницы, которые вызывают у пользователя улыбку вместо разочарования от того, что адрес страницы неправильный.
При создании страницы 404 есть важная техническая составляющая, которая сильно влияет на ранжирование сайтов в поисковых системах, если все не настроено правильно.

Если вы озадачились созданием страницы 404, то вам нужно учитывать три момента:
1) Переадресация со всех неправильно введенных url на страницу 404 в. htaccess.
2) Правильный ответ сервера после переадресации (http-код страницы должен быть 404, а не 200).
3) Закрытие страницы 404 от индексации в robots.txt

Сразу отмечу, что все вышеизложенное написано для самописных сайтов, преимущественно на php. Для wordpress существуют плагины по настройке того же самого. Но в этой статье мы рассмотрим, как все выглядит в реальности. %)

Переадресация (редирект) неправильных url на страницу 404

Первое, что вы делаете – создаете саму страницу 404, чтобы было куда людей посылать %).
Перенаправление url настраивается в файле.htaccess
Просто вписываете строчку:
ErrorDocument 404 http://mysite.com/404.php
Где «mysite.com» – ваш домен, а http://mysite.com/404.php — путь к реальной странице. Если ваш сайт на html, то строка будет выглядеть как:
ErrorDocument 404 http://mysite.com/404.html
Проверка очень проста. После заливки на хостинг файла.htaccess с вышеуказанной строкой, делаете проверку, вводя заведомо не существующий урл (битая ссылка), например: http://mysite. com/$%$%
Если переадресация на созданную вами страницу произошла, значит все работает.
Итак, полностью файл.htaccess, где настроена ТОЛЬКО переадресация на 404 будет выглядеть так:
____________________________
RewriteEngine on
ErrorDocument 404 http://mysite.com/404.html
____________________________

Правильный ответ сервера (http-код страницы)

Очень важно, чтобы при перенаправлении был правильный ответ сервера, а именно – 404 Not Found.
Тут следует объяснить отдельно.

Любому url при запросе назначается статус (http-код страницы).
Для всех существующих страниц, это: HTTP/1.1 200 OK
Для страниц перенаправленных: HTTP/1.1 302 Found
Если страницы не существует, это должен быть HTTP/1.1 404 Not Found

То есть, какой бы урл не был введен, ему присваивается статус, определенный код ответа сервера.
Проверить ответ сервера можно на такой ресурсе как bertal.ru или SEARCH CONCOLE GOOGLE – Сканирование/Посмотреть как GOOGLE бот.
Когда у вас не было перенаправления через.htaccess на страницу 404, то на любой несуществующий урл, введенный пользователем, а также на битые ссылки был ответ «HTTP/1.1 404 Not Found»

После того, как вы настроили перенаправление на свою авторскую страницу 404 через.htaccess, как описано выше, то вводя битую ссылку (неверный url, который заведомо не существует), типа http://mysite.com/$%$% , ответ сервера будет:
— сначала HTTP/1.1 302 Found (перенаправление),
— а затем HTTP/1.1 200 OK (страница существует).

Проверьте через bertal.ru .
Чем это грозит? Это будет означать, что гугл в свою базу данных (индекс) может внести все битые ссылки, как существующие страницы с содержанием страницы 404. По сути — дубли страниц. А это невероятно вредно для поисковой оптимизации.

В этом случае нужно сделать две вещи:
1) Настроить правильный ответ сервера на странице 404.
2) Закрыть от индексирования страницу 404. Это делается через файл robots.txt

Настраиваем ответ сервера HTTP/1.

1 404 Not Found для несуществующих страниц

Ответ сервера настраивается благодаря функции php в самом начале страницы:

Пишите ее вначале файла 404.
В результате мы должны получить ответ на битую ссылку:

Закрыть страницу 404 от индексирования

Закрыть страницу от индексирования можно в файле rodots.txt. Будьте внимательны с этим инструментом, ведь через этот файл ваш сайт, по сути, общается с поисковыми роботами!
Полный текст файла rodots.txt, где ТОЛЬКО закрыта индексация 404 страницы, выглядит так:
____________________________
User-agent: *
Disallow:
Disallow: /404.php
____________________________

Замечания по коду: «/404.php» означает путь к странице. Если на вашем сайте страница 404.php (или 404.html соответственно) находится в какой-то папке, то путь будет выглядеть:
/holder/404.php
где «holder» — название папки.

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

Отладка по HTTP статусу / Девман

По HTTP статусам клиент узнаёт результат своего запроса к серверу. В качестве клиента часто выступает браузер, в качестве сервера — сайт. Если браузер делает запрос к странице, которая была перенесена на другой URL, сайт возвращает ему ответ со статусом 302. Так браузер понимает, что страница была перенесена на другой адрес. Он автоматически переходит по новому адресу, который ему сообщил сервер в том же ответе.

Клиент — это не всегда браузер. Если вы делаете запрос к API ВКонтакте, вы тоже клиент. И в ответе от сайта вам тоже вернётся статус. Стоит разбираться в статусах ответов, чтобы понимать, что сервер хотел вам сказать.

Статус ответа всегда состоит из трёх цифр. Первая цифра указывает тип ответа:

  • 1 — информационный. Он редко встречается. Например, 101, «Switching Protocols». Если отправить запрос по адресу http://some_site.com, а сайт хочет общаться по HTTPS, он попросит вас переключиться с помощью этого статуса.
  • 2 — успешный. Ответ 200 так и называется: «OK».
  • 3 — перенаправление. Если сайт переехал на новый адрес, вы получите 301 —«Moved Permanently».
  • 4 — ошибка клиента. Если клиент попросил страницу, которой на сайте нет, он получит 404 — «Not Found». С сайтом всё в порядке, ошибка в запросе.
  • 5 — ошибка сервера. Если сайт не работает, вы получите 500 — «Internal Server Error». Разработчики сайта что-то поломали, клиент не виноват.

Диагностика ошибок

Для начала узнайте статус ответа:

Если пользуетесь requests:

response = requests.get('https://dvmn.org')
print(response. status_code)  # выведет в консоль 200

Если используете urllib:

response = urllib.urlopen('https://dvmn.org')
print(response.getcode())  # выведет в консоль 200

Но если статус 200, это не значит, что ошибки нет. Это зависит от добросовестности разработчиков. API ВКонтакте всегда присылает 200, а ошибки прячет в текст ответа.

Посмотреть ответ через requests:

response = requests.get('https://api.vk.com/method/wall.post')
print("status:", response.status_code)
print("text:", response.text)

Посмотреть через urllib:

response = urllib.urlopen('https://api.vk.com/method/wall.post')
print("status:", response.getcode())
print("text:", response.read())

В обоих случаях выведется:

status: 200
text: {
    "error": {
    "error_code": 15,
    "error_msg": "Access denied: user should be group editor",
    ...
}

401 Unauthorized, не авторизован

Сервер хочет убедиться, что вы тот, за кого себя выдаёте. Ему нужен ваш логин/пароль или специальный ключ — «токен». Без этого он откажется с вами работать.

Процесс передачи логина/пароля или токена и называют “Авторизация”.

Как исправить

Приложите к запросу токен или логин/пароль. Действуйте так, как указано в документации к API. Как передать токен.

403 Forbidden, доступ запрещён

Сервер решил, что у вас нет доступа к методу, который вы вызвали.

401 и 403 похожи, ведь если вы не не авторизованы, то и доступ вам запрещён. Но всё же у 403 бывает и другое значение: возможно, вы авторизованы, но у вас нет прав. Если вы хотите получить переписки другого пользователя, вы получите 403.

Как исправить

Возможно, вы не авторизовались, а метод требует авторизации. Как это сделать ищите документации к API, которым пользуетесь. Как передать токен.

Вы могли авторизоваться, но неправильно. То есть отправили токен, но сервер не нашёл его в запросе, потому что искал в другом месте. Сверьтесь с документацией к API, которым пользуетесь. Убедитесь, что отправляете токен в аргументе/заголовке с правильным названием.

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

404 Not Found, не найден

Вы пытаетесь обратиться по адресу, на котором ничего нет.

Как исправить

Скорее всего, вы опечатались в адресе. Проверьте в документации адрес метода к которому шлёте запрос.

Возможно, дело снова в авторизации. Иногда сервер отвечает 404, чтобы скрыть, что такая страница вообще существует. Как авторизоваться ищите в документации API, которым пользуетесь.

405 Method Not Allowed, метод не поддерживается

Сервер получил запрос с методом, который не ожидал.

Как исправить

Лучший способ — найти в документации, какой метод использовать.

Если не получилось, попробуйте угадать. Чаще всего используют GET и POST.

406 Not Acceptable, неприемлемо

Сервер не знает как ему перевести данные из одного формата данных в другой.

Как исправить

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

Коды ответов 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.

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

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

410 — (Gone — Исчез)

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

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

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

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

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

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

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/

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

Спросил

Изменено 1 год, 9 месяцев назад

Просмотрено 6k раз

Я пытаюсь выполнить повторное развертывание с 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

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

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

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

Обязательно, но не отображается

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

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

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

Что это такое и как это исправить

Ошибка 404 Not Found — это код состояния ответа HTTP, который указывает, что запрошенный ресурс не найден. Как и в случае с большинством кодов ответа HTTP, причину ошибки 404 Not Found может быть сложно отследить и устранить.

В этой статье будет рассмотрена ошибка 404 Not Found и рассмотрены возможные причины этой ошибки. Позже мы дадим несколько советов по диагностике и отладке ошибки 404 вашего приложения.

Итак, приступим!

Серверная или клиентская сторона?

Все коды состояния ответа HTTP в категории 4xx являются ответами об ошибках клиента. Эти типы сообщений контрастируют с ошибками категории 5xx, такими как 502 Bad Gateway Error, которые являются ответами сервера на ошибку.

При этом появление ошибки HTTP 404 не всегда означает, что проблема связана с клиентом (веб-браузер или устройство, используемое для доступа к приложению). Иногда корень проблемы находится на стороне сервера. Помните, что сервер по-прежнему является сетевым объектом, выдающим ошибку 404 Not Found.

В следующих разделах мы рассмотрим некоторые сценарии (и возможные решения), в которых ошибка возникает из-за проблем с сервером и/или клиентом.

Начните с полной резервной копии приложения

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

После того, как вы это сделали, пришло время начать диагностику и исправление ошибки 404.

Диагностика ошибки 404 Not Found

Ошибка HTTP 404 возникает, когда ресурс недоступен. Клиент (веб-браузер) получил сообщение от сервера (удаленного компьютера) о том, что конкретный ресурс (веб-страница/URL) недоступен.

Вот несколько сценариев, в которых это может произойти: 

  • Клиент отправил правильный запрос на сервер, и сервер успешно получил этот запрос, и сервер не смог найти допустимый ресурс в этом конкретном месте. Обычно это происходит из-за недопустимого URL-адреса, указанного клиентом. Это представляет собой большинство ошибок 404 Not Found Errors.
  • Некоторые веб-приложения «подделывают» 404 Not Found Errors при запросе недопустимого ресурса. Сервер возвращает стандартный код ответа 200 OK, что означает, что ресурс загружен, как и ожидалось, однако сервер отобразил пользовательскую «страницу 404». Такие поддельные ошибки обычно называются программными ошибками 404. 
    • .

Предоставленный URL-адрес мог быть действительным в прошлом, но серверу не удалось обеспечить перенаправление на стороне сервера.

Устранение неполадок на стороне клиента

Лучший способ начать поиск и устранение ошибки 404 Not Found Error — найти потенциальные проблемы на стороне клиента. Вот несколько советов, которые можно попробовать в браузере или на устройстве, на котором возникают проблемы.

Проверьте запрошенный URL-адрес

Наиболее распространенной причиной ошибки 404 Not Found является ввод неверного URL-адреса. Доменные имена (например, airbrake.io) нечувствительны к регистру, а это означает, что эта смешанная ссылка на AirBrAKe.IO работает так же хорошо, как и стандартная версия airbrake.io в нижнем регистре. Однако части пути, запроса или фрагмента, которые появляются после имени домена, часто чувствительны к регистру, если конфигурация приложения/сервера предварительно не обрабатывает все URL-адреса как строчные перед выполнением.

Например, хотя airbrake.io может быть в верхнем, нижнем или смешанном регистре, ссылка на airbrake.io/ERROR-MONITORING/ (с BLOG в верхнем регистре) недействительна, что приводит к нашему хорошему другу 404 Not Found Error.

Конечно, строчная версия https://www.airbrake.io/error-monitoring работает нормально, как и ожидалось.

Как видите, незначительная опечатка в части URL-адреса может легко привести к неожиданной ошибке 404 Not Found.

Очистить соответствующие файлы cookie

Как вы, возможно, уже знаете, файлы cookie HTTP — это крошечные фрагменты данных, хранящиеся на вашем локальном устройстве. Веб-сайты и приложения используют эти файлы cookie, чтобы «запоминать» информацию об этом конкретном браузере и/или устройстве.

Большинство современных веб-приложений используют файлы cookie для хранения данных пользователя и браузера. Таким образом, приложение может идентифицировать клиента и сделать будущие посещения более быстрыми и простыми.

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

В большинстве случаев вам нужно заботиться только о файлах cookie, относящихся к веб-сайту или приложению, вызывающему проблему. Файлы cookie хранятся на основе доменного имени веб-приложения, поэтому вы можете явно удалить только те файлы cookie, которые соответствуют домену веб-сайта (например, airbrake. io).

Однако, если вы не знакомы с удалением определенных файлов cookie вручную, гораздо проще и безопаснее удалить сразу все файлы cookie.

Очистка файлов cookie может выполняться различными способами в зависимости от используемого браузера:

  • Гугл Хром
  • Internet Explorer
  • Microsoft Edge
  • Мозилла Фаерфокс
  • Сафари
Выйдите из системы и снова войдите в систему

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

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

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

Для большинства веб-приложений выход из системы и повторный вход в нее вызовут повторное создание маркера локального сеанса.

Отладка распространенных платформ

Если на сервере, который отвечает с ошибкой 404 Not Found, используются распространенные программные пакеты, вы можете начать с проверки стабильности и функциональности этих платформ.

Наиболее распространенные системы управления контентом, такие как WordPress, Joomla! и Drupal, как правило, хорошо протестированы «из коробки». Тем не менее, как только вы начнете изменять базовые расширения или код PHP, легко вызвать непредвиденную проблему, которая приведет к ошибке HTTP 404.

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

Откат последних обновлений

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

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

Чтобы получить помощь в выполнении этой задачи, просто введите в Google запрос «понижение версии [PLATFORM_NAME]» и следуйте инструкциям. Однако в некоторых случаях некоторые CMS не предоставляют возможности перехода на более раннюю версию. Обычно это относится к более популярным платформам.

Удаление новых расширений, модулей или подключаемых модулей

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

Имейте в виду, что некоторые расширения могут получить полный контроль над системой. После этого они могут вносить практически любые изменения в код PHP, HTML, CSS, JavaScript или базу данных. Таким образом, может быть целесообразно удалить все недавно добавленные расширения, если вы столкнулись с ошибкой 404.

Проверка на наличие непредвиденных изменений базы данных

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

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

Если вы уверены, что причиной ошибки 404 Not Found является расширение, откройте базу данных и вручную просмотрите таблицы и записи, которые, вероятно, были изменены расширением.

Устранение неполадок на стороне сервера

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

Проверьте конфигурацию веб-сервера

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

Например, сервер может быть настроен на отклонение запросов к определенным каталогам или URL-адресам, что приводит к ошибке 404 Not Found.

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

  • Apache
  • Nginx
  • ИИС
  • Node.js
  • Апач Томкэт

Просмотрите журналы

Почти каждое веб-приложение хранит в той или иной форме журналы на стороне сервера. Журналы приложений обычно представляют собой историю действий приложения, включая запрошенные страницы, подключенные серверы, результаты базы данных и т.  д.  

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

Google «logs [PLATFORM_NAME]», если вы используете CMS, или «logs [PROGRAMMING_LANGUAGE]» и «logs [OPERATING_SYSTEM]», чтобы получить дополнительную информацию о поиске журналов, о которых идет речь.

Проверка ссылок на приложения

Существует несколько инструментов, которые можно использовать, чтобы убедиться, что ваше приложение не выдает никаких ошибок 404 Not Found.

Для начала вам следует зарегистрировать свой сайт в Google Search Console (если вы еще этого не сделали). Этот инструмент дает вам представление о том, что роботы поискового робота Google нашли при обходе вашего сайта.

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

Нужно проверить определенный ресурс или URL? Используйте инструмент W3C Link Checker для проверки ссылок на наличие ошибок 404.

Отладка кода или сценариев вашего приложения

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

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

Разнорабочий API | Пустой список, код состояния HTTP 200 против 204 против 404

Выбор кодов состояния HTTP. Часть 4
Арно Лоре, 2 июня 2021 г.

При разработке API выбор кодов состояния HTTP не всегда так очевиден и подвержен ошибкам, я надеюсь, что эта серия постов поможет вам избежать распространенных ошибок и выбрать адаптированный код в соответствии с контекст. Этот четвертый пост отвечает на следующий вопрос: учитывая, что /users — это коллекция (список) и нет пользователей с именем Spock, что должно возвращать GET /users?name=spock? 200 OK , 204 Нет содержимого или 404 Не найдено

При разработке API выбор кодов состояния HTTP не всегда очевиден и подвержен ошибкам, я надеюсь, что эта серия постов поможет вам избежать распространенных ошибок и выбрать адаптированный в соответствии с контекстом.

Я никогда не помню, в каких RFC определены коды состояния HTTP. Чтобы получить быстрый доступ к их документации, я использую веб-концепции Эрика Уайльда.
Особая благодарность всем пользователям Twitter, участвовавшим в опросах и обсуждениях #choosehttpstatuscode

  • 1 — это не тот метод HTTP, который вы ищете, код состояния HTTP 404 против 405 против 501
  • 2 — Руки прочь от этого ресурса, код состояния HTTP 401 против 403 против 404
  • 3 — Идем дальше, здесь нет ресурсов для просмотра (правда), код состояния HTTP 204 vs 403 vs 404 vs 410
  • 4 — Пустой список, код состояния HTTP 200, 204 и 404

Когда вам нужно представить списки (также известные как ресурсы коллекции) в REST/RESTful/RESTish API, обычный шаблон проектирования должен быть представлен с ними как /resources (или /resource , правила чтения /resources и /resource хреново. .. или наоборот?). Чаще всего вам нужно иметь возможность возвращать подмножество элементов списка. Для этого обычным (если не стандартным) шаблоном проектирования является добавление параметров запроса для обеспечения поисковых фильтров. Если GET /users должен возвращать список, содержащий всех (фактически доступных потребителю и, возможно, конечному пользователю) пользователей, GET /users?name=spock должен возвращать список, содержащий только пользователей, чье имя это спок . Вопрос, на который мы ответим сегодня, в основном таков: какой код состояния HTTP отвечает при возврате пустого списка.

По данным моего пула в Твиттере, 51% респондентов вернули бы 200 OK , а 24% вернули бы 204 Нет контента и 25% вернут 404 Не найдено . Давайте посмотрим, какими могут быть правильные ответы в соответствии с RFC(ами) и общепринятой практикой.

Код состояния 200 (ОК) означает, что запрос выполнен успешно.

Начнем с наиболее распространенного и действительного ответа в таком случае: 200 OK . При ответе на GET /users API ответит этим кодом состояния HTTP вместе со списком всех пользователей (фактически доступных для потребителя и, возможно, для конечного пользователя). При ответе на GET /users?name=smith , API также ответит, что с кодом состояния HTTP вместе со списком содержатся все пользователи с именем smith . И, наконец, при ответе на GET /users?name=spock и если нет имени пользователя spock , API ответит еще раз с этим кодом состояния HTTP, но на этот раз вместе с пустым списком. На самом деле это самый распространенный ответ, который я когда-либо видел, вероятно, потому, что большинство людей считают, что ресурс /users collection/list существует и имя Параметр запроса используется для фильтрации содержимого списка.

Но есть и более конкретный код состояния HTTP, который тоже может помочь.

Код состояния 204 (Нет содержимого) указывает на то, что сервер успешно выполнил запрос и что в теле полезной нагрузки ответа нет дополнительного содержимого для отправки.

Хотя 200 OK является допустимым и наиболее распространенным ответом, возврат 204 No Content может иметь смысл, поскольку возвращать абсолютно нечего. Это действительно чаще используется при ответе на PUT (замена) или PATCH (частичное обновление), когда серверы не хотят возвращать замененный/обновленный ресурс или DELETE , потому что после удаления обычно нечего возвращать. Но его можно использовать и на GET . Если запрос действителен, был успешно выполнен и если нет дополнительного содержимого для отправки (в этом случае возвращаемый список будет пустым), 204 Нет содержимого является вполне понятным и действительным ответом.

Это правильный ответ, но я лично не буду его использовать и не рекомендую использовать в таком случае в моем контексте. Потому что это не так распространено (судя по моему опыту, это не абсолютная правда) и может потребовать дополнительной работы. На самом деле, я стараюсь не использовать определенный/необычный HTTP-статус, когда работает и более общий/общий статус, который обычно упрощает работу потребителя, а также работу дизайнера, поскольку вариантов и вариантов поведения меньше (об этом я напишу пост). Хотя потребитель должен уметь интерпретировать любые 2xx как успех и откат, чтобы рассматривать его как 200 OK , это означает, что не будет тела ответа, поэтому нет пустого списка. Это может легко привести к возможному «исключению нулевого указателя» или любому эквиваленту, требующему большего количества элементов управления в коде. 200 OK с пустым списком можно рассматривать так же, как и непустой список, не задумываясь об этом. Обратите внимание, что потребителю, очевидно, придется проверять, пуст ли список или не показывать сообщение конечному пользователю, но точно такой же код будет работать и без этого элемента управления.

Но, упрощая выбор, обратите внимание, что при использовании этого «упрощенного HTTP» вы потеряете некоторую «стандартную семантику HTTP». Действительно, главный аргумент в пользу 204 No Content заключается в том, что он позволяет сравнивать пустые результаты поиска (особенно в журналах) с непустыми, не полагаясь на семантику конкретного тела ответа. Это довольно интересная функция. Возможно, нам нужно больше API-интерфейсов, полностью использующих семантику HTTP, чтобы сделать этот ответ 204 No Content более распространенным и простым.

Таким образом, выбор между 200 OK и 204 Нет содержимого зависит от вас и вашего контекста.

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

Я только что понял, что это четвертый пост в этой серии, и 404 Not Found участвовал во всех постах до сих пор. Давайте посмотрим, что говорят HTTP RFC (с буквой s) об использовании этого варианта использования.

Если мы посмотрим на это определение кода состояния в RFC 7231 и учтем, что /users — это ресурс, используемый даже при выполнении GET /users?name=spock , возвращение этого кода состояния HTTP не имеет никакого смысла. поскольку ресурс /users существует, просто содержащийся в нем список может быть пустым.

Но действительно ли это определение идентификатора ресурса (исключая параметры запроса) является правильным? В разделе 2 RFC 7231 указано , что каждый ресурс идентифицируется с помощью универсального идентификатора ресурса (URI), как описано в разделе 2.7 RFC 7230 9.0067 . В этом разделе 2.7 RFC 7230 говорится, что «запрос» (что находится между первыми ? и # ) является частью идентификатора ресурса. Если мы перейдем по ссылке (это настоящий лабиринт!), ведущей к полному описанию запроса, мы в конце концов придем к разделу 3. 4 RFC 3986, в котором говорится, что компонент запроса содержит неиерархические данные, которые наряду с данными в компоненте пути ( Раздел 3.3) служит для идентификации ресурса . В основном это означает, что /users?name=spock — это идентификатор ресурса, поэтому возврат 404 допустим в соответствии с HTTP RFC, если мы хотим сказать «извините, ни один ресурс не соответствует строгому идентификатору, указанному в вашем запросе» или «нет такого списка пользователей, содержащего пользователей с именем spock». Но использование этого кода состояния HTTP, действительного с точки зрения чистого HTTP, действительно ли хорошая идея использовать его в этом случае использования?

По моему скромному мнению, основанному на моем опыте разработки API, чтении и прослушивании многих практиков API, анализе многих API и проведении сотен обзоров дизайна API, я не рекомендую использовать его в этом случае, потому что это нарушит общепринятую практику. . В большинстве API-интерфейсов REST/RESTful/RESTish «идентификатор ресурса» на самом деле представляет собой путь к ресурсу без части запроса, что может быть неправильным, если говорить строго по HTTP, но это текущее состояние обычной практики. В большинстве API 404 Not Found сильно привязан к «для запрошенного пути ничего нет (кроме параметров запроса)». Он возвращается в случае использования /path-that-does-not-exist или /collection/{id, который не существует} (см. Выбор кодов состояния HTTP, часть 2. Руки прочь от этого ресурса, код состояния HTTP 401 vs. 403 против 404 или Выбор кодов состояния HTTP. Часть 3. Продолжайте, здесь нет ресурсов для просмотра (правда), код состояния HTTP 204 против 403 против 404 против 410), но не для пустых списков (обычно это 2xx Класс успеха ). Кроме того, возврат 4xx Client Error Class говорит о том, что потребитель совершил ошибку, действительно ли это так? Я так не думаю, потребитель просто предоставил поисковые фильтры, которые не соответствуют ни одному элементу в списке.

Это мое аргументированное мнение о том, чтобы не использовать 404 Not Found для пустых списков, но если у вас есть веские причины использовать этот код состояния HTTP для этого варианта использования, не забывайте быть последовательным и предоставлять информативную обратную связь об ошибках. Действительно, если принять как должное, что GET /users?name=spock возвращает 404 Not Found , если нет пользователей с именем spock. Как насчет GET /users , если пользователей вообще нет? Он должен возвращать тот же код состояния HTTP. И чтобы отличить это от более распространенного /путь-который-не-существует , потребуется добавить некоторую информацию в тело ответа, чтобы объяснить фактическую причину этого ответа.

Сегодняшний урок заключается в том, что следование протоколу HTTP — это одно, но иногда существуют различные варианты со своими плюсами и минусами, а иногда чрезмерная строгость может привести к тому, что дизайн будет менее понятным. Вопрос не в достижении наиболее совершенного дизайна (относительно HTTP), а просто в создании дизайна, который имеет смысл для большинства вовлеченных людей и предлагает наилучший DX. И этот D в DX включает в себя не только разработчиков, но и дизайнеров. Простые правила проектирования, понятные большинству, являются ключевым фактором успеха вашего API.

No related posts.