Как получить все ошибки http

Время на прочтение
6 мин

Количество просмотров 16K

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

№1: HTTP статусы

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Success:

HTTP 200 GET /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 404 GET /v1/user/1
Body: 'Не найден пользователь'

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

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание «совы на глобус»: все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

HTTP 400 PUT /v1/task/1 { status: 'doing' }
Body: { error_code: '12', error_message: 'Задача уже взята другим исполнителем' }

Из-за ограниченности http статусов разработчики начинают вводить “свои” коды ошибок для каждого статуса и передавать их в теле ответа. Другими словами, пользователю API приходится писать нечто подобное: 

if (status === 200) {
  // Success
} else if (status === 500) {
  // some code
} else if (status === 400) {
  if (body.error_code === 1) {
    // some code
  } else if (body.error_code === 2) {
    // some code
  } else {
    // some code
  }
} else if (status === 404) {
  // some code
} else {
  // some code
}

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа “Произошла ошибка” или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике.  Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

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

№2: На все 200

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

Вариант 1:

Success:
HTTP 200 GET /v1/user/1
Body: { ok: true, data: { name: 'Вася' } }

Error:
HTTP 200 GET /v1/user/1
Body: { ok: false, error: { code: 1, msg: 'Не найден пользователь' } }

Вариант 2:

Success:
HTTP 200 GET /v1/user/1
Body: { data: { name: 'Вася' }, error: null }

Error:
HTTP 200 GET /v1/user/1
Body: { data: null, error: { code: 1, msg: 'Не найден пользователь' } }

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

Звучит здорово, мы теперь отвязались от http статусов и можем спокойно ввести свои коды ошибок. У нас больше нет проблемы “впихнуть невпихуемое”. Выбор нового типа ошибки не вызывает споров, а сводится просто к введению нового числового номера (например, последовательно) или строковой константы. Например:

module.exports = {
  NOT_FOUND: 1,
  VALIDATION: 2,
 // ….
}

module.exports = {
  NOT_FOUND: ‘NOT_AUTHORIZED’,
  VALIDATION: ‘VALIDATION’,
 // ….
}

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

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

if (status === 200) {
  if (body.error) {
    var error = body.error;
    if (error.code === 1) {
      // some code
    } else if (error.code === 2) {
      // some code
    } else {
      // some code
    }
  } else {
    // Success
  }
} else {
  // transport erros
}

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

Но неудобства тоже есть:

  • Избыточность полей при передаче данных, т.е. нужно всегда передавать 2 поля: для данных и для ошибки. Это усложняет чтение логов и написание документации.

  • При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

  • Мониторинг теперь точно будет срабатывать только на ошибки транспорта, а не бизнес-логики, но для мониторинга логики надо будет дописывать парсинг тела сообщения.

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

  • нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST

  • нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

  • имеются проблемы с документированием – swagger и  ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой  часто именно такой подход и используют.

№3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

Success: 

HTTP 200 /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 400 /v1/user/1
Body: { error: { code: 1, msg: 'Не найден пользователь' } }

Коды:

  • 200 – успех

  • 400 – ошибка бизнес логики

  • остальное ошибки в транспорте

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

if (status === 200) {
  // Success
} else if (status === 400) {
  if (body.error.code === 1) {
    // some code
  } else if (body.error.code === 2) {
    // some code
  } else {
    // some code
  }
} else {
  // transport erros
}

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

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

P.S. Иногда ошибки любят передавать массивом

{ error: [{ code: 1, msg: 'Не найден пользователь' }] }

Но это актуально в основном в двух случаях:

  • Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

  • Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую  в наше API,  не должен нас волновать?HTTP

Источник

Коды статусов и ошибок

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

Содержание раздела

Пример кода статуса в заголовке curl

Где перечислять HTTP-ответ и коды ошибок

Где взять коды статусов и ошибок

Как перечислить коды состояния

Коды состояния и ошибок помогают в устранении неполадок

Примеры кодов статусов и шибок

  • Context.io

  • Twitter

  • Mailchimp

  • Flickr

Практическое занятие: Коды статусов и ошибок

Пример кода статуса в заголовке curl

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

Помните, когда мы отправляли обратный вызов в разделе Создание curl запроса? Чтобы получить заголовок ответа, добавляем —include или -i к запросу curl. Если нужно, чтобы в ответе возвращался только заголовок ответа (и ничего больше), используем заглавную букву -I, например:

curl -I -X GET "https://api.openweathermap.org/data/2.5/weather?zip=95050&appid=fd4698c940c6d1da602a70ac34f0b147&units=imperial"

Заголовок ответа выглядит следующим образом:

HTTP/1.1 200 OK    
Server: openresty
Date: Thu, 06 Dec 2018 22:58:41 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 446
Connection: keep-alive
X-Cache-Key: /data/2.5/weather?units=imperial&zip=95050
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST

Первая строка, HTTP / 1.1 200 OK, сообщает нам статус запроса (200). Большинство API REST следуют стандартному протоколу для заголовков ответов. Например, 200 — это не просто произвольный код, выбранный разработчиками OpenWeatherMap API. 200 — это общепринятый код для успешного HTTP-запроса. (Если изменить метод, то получим другой код состояния.)

С помощью запроса GET довольно легко определить, успешен ли запрос, потому что получаем ожидаемый ответ. Но предположим, делаем запрос POST, PUT или DELETE, когда мы меняем данные, содержащиеся в ресурсе. Как узнать, был ли запрос успешно обработан и получен API? Коды ответа HTTP в заголовке ответа будут указывать, была ли операция успешной. Коды состояния HTTP — это просто сокращения длинных сообщений.

codes

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

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

Можно посмотреть список общих кодов состояния REST API здесь и общий список кодов HTTP статусов здесь. Хотя, возможно, было бы полезно включить несколько стандартных кодов состояния, нет необходимости в полном документировании всех стандартных кодов состояния, особенно если они редко запускаются в API.

Где перечислять HTTP-ответ и коды ошибок

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

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

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

Где взять коды статусов и шибок

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

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

Как перечислить коды состояния

Коды статусов и ошибок можно привести в виде списка определений или таблицы, например так:

Status code Значение
200 Успешный запрос и ответ
400 Неверно заданные параметры или другой неверный запрос

Коды состояния и ошибок помогают в устранении неполадок

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

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

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

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

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

Примеры кодов статусов и ошибок

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

Context.io

conext

Коды статусов и ошибок Conext.io

Clearbit не только документирует стандартные коды состояния, но также описывает уникальные параметры, возвращаемые их API. Большинство разработчиков, вероятно, знакомы с кодами 200, 400 и 500, поэтому эти коды не требуют много пояснений. Но если API имеет уникальные коды, описывать их нужно адекватно и подробно.

Twitter

twitter

Коды статусов и ошибок Twitter

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

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

Mailchimp

Mailchimp

Коды статусов и ошибок Mailchimp

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

Flickr

Flikr

Коды статусов и ошибок Flikr

В Flickr раздел «Коды ответов» встроен в описание каждой адресной темы API. Описания ошибок выглядят короткими. Хотя встраивание кодов ответов в каждую тему делает коды ошибок более заметными, в некоторых случаях такой подход менее полезен. Поскольку он встроен в каждую тему API, описания кодов ошибок должны быть краткими, иначе их содержимое будет перегружено информацией о запросе конечной точки.

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

👨‍💻 Практическое занятие: Коды статусов и ошибок

В своем найденном опен-сорс проекте найдем информацию о кодах статусов и ошибок. Ответим на следующие вопросы:

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

🔙

Go next ➡

Источник

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

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

Что такое код ответа

Код ответа сервера — это ответ сервера на действия пользователя. Он представляет собой целое трёхзначное число, в котором первая цифра определяет класс состояния. Обычно за кодом ответа находится фраза на английском языке — она объясняет человека причину полученного ответа и подсказывает, что делать дальше.

Пример кода ответа сервераПример кода ответа сервера

Набор кодов состояния — стандарт. Все коды описаны в серии пронумерованных информационных документов интернета RFC. Введение новых кодов возможно, но только после согласования c IETF — Инженерным советом Интернета.

Анализ кода состояния HTTP помогает определить доступность веб-страницы. Технически это выглядит так: когда вы переходите по ссылке на сайте или просто вводите её в поисковой строке браузера, отправляется стандартный запрос. Сервер самостоятельно обрабатывает его, а затем формирует и отдаёт трёхзначный цифровой код

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

В кодах сервера нет ничего сложного даже для начинающих вебмастеров. Главное — определиться с терминами:

  • Клиент — компьютер или любое другое устройство, подключённое к интернету.
  • Сервер — конкретный компьютер, где хранятся все данные сайта, в том числе страницы и системные файлы.

Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!

Подписывайся на канал

Подписаться

Когда важно настроить коды ответов сервера

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

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

Классификация кодов

Ответы сервера — трёхзначные коды с небольшим текстовым пояснением. Чтобы ориентироваться в них было проще, их делят на классы состояния. Основной классификационный признак — первая цифра трёхзначного кода.

Значения первых цифр кода ответа сервера:

  • 1xx — коды информации. Они говорят об успешном получении запроса и начале передачи данных.
  • 2xx — коды успешного выполнения запроса. Сигнализируют о положительном ответе сервера в браузере.
  • 3xx — коды перенаправления. Отвечают за переадресацию, используются для навигации между URL.
  • 4xx — коды HTTP-ошибок на стороне пользователя.
  • 5xx — коды HTTP-ошибок в работе сервера. Точная причина сбоя указывается сразу после кода.

Ниже более подробно разберём классы состояния ответов сервера. Для самых часто встречающихся укажем причины и решения ошибок.

Коды информации

В класс 1xx включены коды, которые информируют о процессе передачи.

100 Continue — сервер удовлетворён начальными сведениями о запросе. Устройство-клиент может продолжать отправку данных.

101 Switching Protocols — сервер учитывает пользовательские требования и переключает протоколы.

102 Processing — запрос поступил на сервер, но для его обработки требуется время. Ответ необходим, чтобы клиент не разорвал соединение из-за превышения лимита ожидания.

103 Early Hints — сервер загружает элементы заголовков, если заголовки полного ответа не могут быть сформированы быстро.

Коды успешного выполнения запроса

Ответы класса 2xx показывают, что клиентский запрос был принят и успешно обработан.

200 OK — успешный запрос. Клиент запросил определённые данные, и они отобразились в заголовке или теле сообщения.

201 Created — завершённая транзакция. В результате выполнения запроса появился новый ресурс. Его адрес указывается в теле ответа или заголовке Location.

202 Accepted — запрос принят, но процесс его обработки не завершился. Клиент может не дожидаться передачи сообщения, так как это займёт много времени.

203 Non-Authoritative Information — информацию для передачи взяли не с исходного сервера, а какого-то другого. Данные могут быть устаревшими.

204 No Content — запрос обработан, но содержимое отсутствует. Сервер обработал запрос, но передал только заголовки без тела сообщения.

205 Reset Content — требуется сбросить содержимое. Клиенту нужно обновить введённые пользователем данные, но саму страницу перезагружать не нужно.

206 Partial Content — ошибка частичного содержимого. Клиент загружал данные в несколько потоков, но сервер выполнил частичный GET-запрос. Чтобы устранить ошибку, почистите кэш и проверьте, как выполняются исходящие запросы.

207 Multi-Status — набор выполненных операций. Сервер передал результаты выполнения нескольких операций — они находятся в XML в строке MultiStatus.

Коды перенаправления

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

300 Multiple Choices — не удалось определить точный URL. Существует несколько вариантов предоставления ресурса по разным характеристикам. Сервер передаёт с сообщением список альтернатив, клиент самостоятельно делает выбор.

301 Moved Permanently — документ перемещён на новый URL. Так отвечают все веб-страницы, которые удалены или являются дублями. Со временем они автоматически присоединяются к целевой странице. Если возникла ошибка: настройте 301-ое перенаправление с устаревшего адреса на актуальный.

302 Moved Temporarily — запрошенный документ временно доступен по другому URL. Корректный ответ сервера, который часто используется для страниц с распродажами и сезонными акциями. Клиент находит нужную страницу, несмотря на то что она перенесена.

303 See Other — документ нужно запросить по другому адресу. Такой код получают исключительно GET-запросом. Обычно его используют, если нужно перенаправить пользователя на близкорелевантную, но не идентичную страницу.

304 Not Modified — документ не изменился с указанного момента. Код — стандартный редирект. Помогает поисковым роботам находить страницы, которые не изменились с последнего визита пользователя.

305 Use Proxy — доступ к запрашиваемому ресурсу возможен только через прокси-сервер.

307 Temporary Redirect — документ временно доступен по другому URL. Код разрешает не менять метод запроса. Нужен, чтобы перенаправлять пользователей, но оставлять техническую возможность отправки POST-запросов.

308 Permanent Redirect — запрашиваемый документ окончательно перенесён на новый URL.

Коды HTTP-ошибок на стороне клиента

Класс кодов 4xx помогает найти ошибки со стороны клиента. В теле сообщения сервер отправляет текстовое пояснение для пользователя.

400 Bad Request — некорректный запрос. Сервер обнаружил в запросе клиента синтаксическую ошибку. Чтобы исправить её, проверьте корректность отправляемого запроса.

401 Unauthorized — отсутствует аутентификация. Для получения доступа к запрашиваемому ресурсу клиент должен зарегистрироваться или ввести пароль.

402 Payment Required — отсутствует доступ к документу. Такой код обычно используется платными пользовательскими сервисами. Доступ закрывается, если просрочена оплата.

403 Forbidden — доступ запрещён. Сервер обработал запрос, но отказывается выполнять его из-за ограничений к указанному ресурсу. Наиболее вероятная причина ограничения — попытка доступа к системным ресурсам веб-сервера или к закрытым файлам.

404 Not Found — отсутствует запрос по введённому URL. Обычно ошибка возникает из-за неправильно написанного адреса веб-страницы. Убедитесь, что вы ввели данные правильно.

405 Method Not Allowed — некорректный метод. Указанный клиентом метод запроса нельзя применить к текущему ресурсу. В теле сообщения сервер укажет доступные методы в заголовке Allow.

406 Not Acceptable — неподдерживаемый формат запроса. Сервер не может прислать методы, которые применимы к текущему запросу. Причина — неспособность поисковой системы поддерживать кодировку документа или его язык. Посмотрите в теле сообщения лист доступных ресурсов и выберите один из вариантов.

407 Proxy Authentication Required — отсутствует регистрация прокси. Механизм аналогичен идентификации на исходном сервере по коду 401.

408 Request Timeout — таймаут запроса. Время ожидания сервером истекло, но клиент может повторить аналогичный запрос. Ошибка возникает, если в какой-то момент источник данных перестал отвечать, например, из-за внутренних повреждений или потери связи. Чтобы исправить, проверьте наличие интернета, а затем обновите страницу.

409 Conflict — несовместимость двух запросов. Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Частая причина ошибки — операции с методом PUT. Например, если нужно скачать файл, возраст которого превышает возраст того, что уже размещён на сервере.

410 Gone — ресурс больше не существует по указанному URL, страница удалена или недоступна. Если навсегда удаляете страницу, сделайте так, чтобы она давала именно 410-ый ответ. Тогда поисковый робот научится обходить её. Если удаляете временно, эффективнее использовать 404-ый ответ.

411 Length Required — сервер отклонил отправляемый запрос, поскольку не нашёл значение Content-Length. Ответ может быть получен как при обычных POST-запросах, так и при PUT-запросах.

412 Precondition Failed — ни одно из условных полей заголовка не выполнено. Как исправить: проверьте корректность и соблюдение HTTP-заголовков.

413 Payload Too Large — сервер отказал в обработке запроса из-за слишком большого размера. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 URI Too Long — сервер отказал в обработке запроса из-за слишком длинного URL. Ошибку можно спровоцировать, если вы пытались передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type — некорректный медиаформат. Сервер не смог работать с указанным типом данных при выбранном методе.

416 Range Not Satisfiable — некорректно указанный диапазон, с которым не может взаимодействовать сервис. Ошибка возникает, если допущена опечатка в синтаксисе или диапазон отсутствует в необходимом документе. Чтобы исправить, проверьте синтаксис значения Range и обновите страницу.

417 Expectation Failed — сервер некорректно идентифицирует значение поля Expect заголовка запроса. Вы не сможете самостоятельно устранить ошибку, но можете обратиться в поддержку, если используете прокси Squid. Ещё один вариант — разрешить BS_PingHost обращаться к сети без участия прокси.

422 Unprocessable Entity — сервер принял запрос и может работать с указанным видом данных, но имеется какая-то логическая ошибка, мешающая выполнить операцию. Код не укажет, какая именно ошибка допущена, но чаще всего найти её удаётся в семантике документа.

423 Locked — используемый ресурс заблокировали, поскольку HTTP-метод был выбран неправильно. Перезагрузите интернет-роутер и компьютер, повторите операцию.

424 Failed Dependency — ресурс заблокировали в целях безопасности. Такой ответ отдаётся при наличии признаков несанкционированного доступа к CMS-файлам.

426 Upgrade Required — для продолжения работу клиенту необходимо обновить протокол. Ошибка возникает, если сервер требует обновление до SSL-протокола, а у клиента нет его поддержки.

429 Too Many Requests — клиент пытался отправить слишком много запросов за короткий промежуток времени. Ошибка возникает, потому что такая активность напоминает DDoS-атаки. Чтобы исправить её, отключите все плагины CMS, а затем включите их по очереди. Так вы найдёте источник проблемы.

451 Unavailable For Legal Reasons — доступ к странице закрыт по решению суда. Наиболее частая причина — нарушение авторских прав. Вы можете попытаться создать дубли, но рано или поздно ресурс с идентичным содержимым заблокируют. Временное решение — сменить домен. Но лучше всего — не нарушать закон.

Коды HTTP-ошибок на стороне сервера

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

500 Internal Server Error — любой внутренний сбой сервера, из-за которого не удаётся выполнить запрос. Часто проблема заключается в некорректно указанных директивах в системных файлах или в опечатках внутри скриптов. Как исправить ошибку: проверьте конфликты плагинов и дополнений. Возможно, в настройках административной панели указана одна версия PHP, а на сайте применяется другая, из-за чего создаётся высокая нагрузка на хостинг.

501 Not Implemented — не поддерживаются возможности, необходимые для обработки запроса. Сервер не понимает выбранный метод запроса, поэтому происходит ошибка. Исправить её самостоятельно вы не сможете.

502 Bad Gateway — сбой шлюза. Вышестоящий сервер отправил некорректный ответ серверу, выступающему в роли шлюза или прокси-сервера.

503 Service Unavailable — запрос не обработан по техническим причинам. Ошибка возникает, если сервер на обслуживании или сильно перегружен. Убедитесь, что пропускная способность сервера не ограничена профилактическими работами и отключите VPN.

504 Gateway Timeout — прокси-сервер не дождался ответа от вышестоящего сервера. Попробуйте обновить страницу. А если не помогло — почистите DNS-кэш. Для этого нажмите клавиши Windows и R, введите команду cmd. В открывшемся окне выберите ipconfig/flushdns и нажмите Enter.

505 HTTP Version Not Supported — сервер не поддерживает выбранную версию HTTP-протокола.

507 Insufficient Storage — на жёстком диске отсутствует место для выполнения запроса.

510 Not Extended — на сервере нет расширения, которое пытается использовать клиент. В теле сообщения сервер укажет, какие расширения доступны.

Как узнать код ответа сервера

Вы можете проверить код ответа сервера через опции браузера или специальные приложения. Например, в Google Chrome значение кода отображено в графе Status в разделе Network. Чтобы получить данные:

  • откройте в браузере нужную страницу;
  • активируйте функциональную панель вебмастера, нажав кнопку F12.

активируйте функциональную панель вебмастера, нажав кнопку F12

Ещё один вариант узнать ответ веб-страницы — использовать готовые сервисы: bertal, 2ip, cy-pr, wwhois, 4seo.

Рассмотрим, как они работают на примере mainspy:

  1. Перейдите на официальный сайт сервиса.

Перейдите на официальный сайт сервиса

  1. Укажите URL для проверки — один или несколько.

Укажите URL для проверки — один или несколько

  1. Нажмите кнопку «Проверить».

Нажмите кнопку «Проверить»

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

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

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

Чтобы правильно истолковать ответ такого севера, базовых знаний недостаточно. Записывайтесь на курсы по веб-разработке, чтобы восполнить пробелы в знаниях и научитесь переводить такие коды ответов на человеческий язык.

Источник

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

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

Что такое код ответа сервера?

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

1xx — информационные:

  • 100 — сервер принял первую часть запроса, можно подрожать передачу;
  • 101 — нужно изменить протокол работы на более подходящий;
  • 102 — на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх — операция успешна:

  • 200 — запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
  • 201 — после выполнения запроса был создан ресурс;
  • 202 — запрос принят, но еще не обработан;
  • 203 — запрос выполнен успешно, но информация для ответа взята из прокси;
  • 204 — запрос обработан, но контента для отображения нет;
  • 205 — попросить пользователя ввести необходимые данные;
  • 206 — запрос обработан, но передана только часть контента;

3xx — перенаправления:

  • 300 — есть несколько страниц для этого запроса, например, на нескольких языках;
  • 301 — страница навсегда перемещена по новому адресу;
  • 302 — документ был временно перемещен;
  • 303 — документ необходимо загрузить по указанному адресу с помощью протокола GET;
  • 304 — документ не изменился с последнего запроса;
  • 305 — нужно использовать прокси;
  • 307 — ресурс временно перемещен на новый адрес.

4хх — ошибка в запросе:

  • 400 — неверный запрос;
  • 401 — необходимо аутентифицироваться;
  • 403 — запрос принят, но у вас нет доступа;
  • 404 — страница не найдена на сервере;
  • 405 — используемый метод нельзя применять на сервере;
  • 408 — время ожидания передачи запроса истекло;
  • 410 — ресурс полностью удален;
  • 411 — нужно указать длину запроса;
  • 413 — запрос слишком длинный;
  • 414 — URI запроса слишком длинная.

5хх — ошибка сервера:

  • 500 — внутренняя ошибка сервера;
  • 501 — нужная функция не поддерживается;
  • 502 — прокси не может соединиться со шлюзом;
  • 503 — сервер не может обрабатывать запросы по техническим причинам;
  • 504 — прокси не дождался ответа от сервера;
  • 505 — версия протокола HTTP не поддерживается.

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

  • Server — имя и версия веб-сервера;
  • Date — дата осуществления запроса;
  • Content-Type — MIME тип передаваемых данных, например, text/html, тут же задается кодировка;
  • Connection — тип соединения, может быть closed — уже закрыто, или keep-alive — открыто для передачи данных;
  • Vary — указывает при каких заголовках веб-сервер будет возвращать разные старины для одного URI;
  • Set-Cookie — сохранить Cookie информацию для страницы;
  • Expires — можно хранить страницу или ресурс в кэше до определенной даты;
  • Cache-Control — настройка времени кэширования страницы браузером, а также разрешения на кэширования;
  • ETag — содержит контрольную сумму для страницы, применимо для проверки кэша;
  • Last-Modified — дата, когда страница последний раз была изменена;

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

Проверка кода ответа сервера с помощью cURL

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

curl -s -o /dev/null -w "%{http_code}" https://losst.pro

Или, если хотите, чтобы ответ выглядел более естественно:

curl -I https://losst.pro 2>/dev/null | head -n 1 | cut -d$' ' -f2

Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:

curl -I http://losst.pro 2>/dev/null | head -n 1 | cut -d$' ' -f2

curl -I https://www.losst.pro 2>/dev/null | head -n 1 | cut -d$' ' -f2

Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

curl -I https://losst.pro

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

  • Страница сгенерирована в nginx 1.10.2;
  • Это обычная html страница (text/html);
  • Размер страницы 102452 байт или 100 кб;
  • Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
  • Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
  • Страница может храниться в любом кэше (public) на протяжении часа (expires);

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

 curl -I https://losst.pro/wp-content/uploads/2016/08/map-2.png

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй — по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

curl -I https://losst.pro

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

curl -I --header 'If-Modified-Since: Mon, 26 Dec 2016 18:13:12 GMT' https://losst.pro

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

curl -I https://losst.pro

Затем отправим полученную сумму с заголовком:

curl -I --header 'If-None-Match: "58615db8-19034"' https://losst.pro

И снова мы должны получить ответ 304, страница не изменена.

Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

 curl -I https://losst.pro --header 'Accept-Encoding: gzip'

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Выводы

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

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Источник

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

Что такое код сервера

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

Страница с кодом ответа сервера Discord при переходе на несуществующую страницуСтраница с кодом ответа сервера Discord при переходе на несуществующую страницу

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

Читайте также: 11 способов проверки битых ссылок на сайте

Какие бывают коды ответов

Классы состояния — это группы кодов, которые объединяются общими признаками. Всего есть пять классов: принадлежность определяется первой цифрой из трех.

Класс 1. Выглядит так: 1ХХ. Это временные информационные коды. Они сообщают о том, что запрос принят и находится в обработке.

Класс 2. Выглядит так: 2ХХ. Сообщает об успешной обработке запроса.

Класс 3. Выглядит так: 3ХХ. Сообщает о перенаправлении с одного адреса на другой. Эти коды говорят об изменении URL. Используются при создании зеркал или переносе сайта на новый движок.

Класс 4. Выглядит так: 4ХХ. Говорит об ошибке со стороны посетителя. Обычно после числа идет небольшой текст с объяснением — в чем проблема. Такие коды говорят о запрете просмотра страницы или об ее отсутствии.

Класс 5. Выглядит так: 5ХХ. Сообщает об ошибке со стороны сервера. После этого класса тоже следует текстовое сообщение с объяснением причины поломки. 

Теперь разберем более распространенные виды ответов в каждом классе.

Класс 1

100 Continue. Промежуточный ответ сервера. Говорит о том, что сервер принял запрос и начинает обработку.

101 Switching Protocols. Код ответа указывает протокол, который переключает сервер, используя запрос Upgrade. В ответ сервер отправляет заголовок ответа Upgrade с указанием протокола, на который переключился.

102 Processing. Это значит, что сервер получил запрос и обрабатывает его. Клиент не должен разрывать соединение, чтобы дождаться ответа от сервера. Этот код используется в протоколе WebDAV (измененный HTTP для работы с файлами).

Класс 2

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

202 Accepted. Запрос принят и будет обрабатываться долго. Пользователь может не дожидаться окончания запроса. Используется, когда запрос обрабатывается другим сервером. Такой код используется сервером, чтобы выполнять несколько запросов одновременно: пока пользователь с кодом 202 ждет окончания операции, 200 уже «видит» страницу.

203 Non-Authoritative Information. Код означает, что обработка запроса прошла успешно. Но информация поступила не от сервера, а от другого источника: облака, резервной копии.

204 No Content. Такой код используется на портал для запуска скриптов. Например, когда пользователь кликает по свободному месту на сайте.

205 Reset Content. Говорит о том, что браузеру нужно очистить форму, в которую вписаны данные. Такой код используется, чтобы очистить поля, заполненные при регистрации. При это обновлять ресурс не нужно.

Класс 3

300 Multiple Choices. Говорит о том, что указанный URL обозначает больше, чем один ресурс. Например, страницу, переведенную на несколько языков. 

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

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

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

303 See Other. Указывает, что происходит перенаправление на другую страницу. Чтобы новая страница индексировалась, она должна отвечать на код 200. Такой код используется для страниц с подтверждением. Например, когда сайт высылает код подтверждения регистрации. 

304 Not Modified. Это значит, что предыдущая версия страницы не изменена. Благодаря этому робот индексирует ее без загрузки. Из-за этого сервер меньше нагружается и повышается время безотказной работы. А пользователь работает с версией страницы, которая сохранена в памяти браузера. 

У пользователей часто возникает ошибка HTTP 304. Такое бывает, если компьютер заражен вирусами или Windows медленно работает. Чтобы решить проблему, нужно проверить ПК на вирусы и очистить от лишних файлов. Еще можно восстановить записи в реестре системы. Но такую процедуру лучше доверить мастерам сервисного центра: если делать самостоятельно, можно превратить ПК в «кирпич».

305 Use Proxy. Сайт будет доступен только при использовании прокси-сервера. При этом нужно использовать сервер, который указан в разделе Location. Такой код предназначен для защиты сайта. 

308 Permanent Redirect. Полностью повторяет запрос 301. Разница в методе выполняемого запроса.

Класс 4

400 Bad Request. Сервер не может понять запрос, потому что он введен с ошибкой. Под ошибкой обычно понимается синтаксическая: некорректно введен URL. Также код 400 появляется, когда пользователь пытается загрузить на сайт слишком большой файл. Решить проблему помогает смена запроса или очистка cookies. Чтобы очистить куки в браузере, нужно перейти в настройки, в раздел конфиденциальности и безопасности.

401 Unauthorized. У клиента не получается зайти на страницу сайта, потому что у него не хватает прав доступа. Такая ошибка возникает на сайтах, где есть форма для авторизации. Решить ошибку можно двумя способами: войти в систему с использованием логина и пароля или очистить кэш браузера.

403 Forbidden. Этот код говорит о запрете на просмотр страницы. Такое бывает, если для IP-адреса внесен запрет на уровне сервера. Решить проблему можно с помощью VPN или прокси.

Что такое прокси? Как выбрать качественный прокси-сервер? Прокси для SEO, парсинга, арбитража и пр.

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

Ошибка 404 влияет на SEO-оптимизацию: если страница не существует / не доступна, поисковые роботы не будут ее индексировать и показывать в поиске. А еще переходы по битым ссылкам ухудшают поведенческие факторы. Но нивелировать негатив поможет грамотное оформление 404-страницы. Можно сделать ее с юмором, перенаправить трафик на другие ресурсы.

405 Method Not Allowed. Соответствующий код появляется, если на этапе обработки запроса сервер получает запрет. Такое случается, если нарушается работа php-скриптов. Ошибку можно решить с помощью перезагрузки страницы. Также помогает проверить все скрипты и удалить дополнения в CMS. 

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

409 Conflict.Означает конфликт между пользовательским запросом и сервером. Например, клиент хочет скачать с сайта файл «фото01». Но раньше файл назывался «фото1» и это название сохранилось в кеше. Из-за этого сервер не понимает, что хочет скачать пользователь — возникает конфликт.

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

413 Request Entity Too Large. Ошибка возникает, если пользователь пытается загрузить слишком большой файл на сайт. Стандартно допустимый размер загружаемого файла — 1 Мб. Если клиент пытается загрузить больше — возникает ошибка. Чтобы решить проблему, нужно увеличить размер максимально загружаемого файла. Для этого нужно вносить изменения в настройки Nginx, php и apache. (Есть видео, как это делать в CMS WordPress.)

414 Request-URL Too Long. Если пользователь пытается сделать запрос с длинным URL, возникает такая ошибка.

423 Locked. Такая ошибка возникает, если IP-адрес блокируется хостером. Блокировку можно получить за сильную активность, интернет-мошенничество или вирусы. 

451 Unavailable For Legal Reasons. Новая ошибка, которая набирает популярность. Она появляется на сайтах, которые заблокированы государством. Ошибка 451 — дополнение к 403.

Класс 5

500 Internal Server Error. Ошибка из-за сбоев на сервере. Возникает при неправильной конфигурации файла .htaccess. Чтобы решить проблему, нужно изменить директиву Options: поставить в начале строки #.

502 Bad Gateway. Возникает, если есть промежуточный сервер. Случается, когда промежуточный сервер получает запрос и запрашивает данные у «главного» сервера, и получает неправильный ответ. В решении ошибки помогает очистка кеша браузера, обновление страницы и очистка DNS-кеша.

503 Service Unavailable. У сервера не получается обрабатывать запросы по техническим причинам. Например, если на сервере ведутся какие-то работы.

504 Gateway Timeout. Шлюз не дает ответа. Появляется, если ответ от главного сервера не получен.

507 Insufficient Storage. Ошибка высвечивается, если у сервера нет места работы с операцией. Проблему можно решить перезагрузкой. Или просто подождать.

511 Network Authentication Required. Значит, что нужно пройти авторизацию для доступа к интернету. Такой ответ высылает посредник, например, провайдер. Чтобы решить проблему, нужно написать в поддержку провайдера.

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

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

Начнем с ручного способа. Для этого перейдите на сайт через браузер Chrome и откройте консоль клавишей «F12». (Или «Fn + F12» на ноутбуках. Также инструменты разработчика можно включить сочетанием клавиш «Ctrl + Shift + I».) Теперь перейдите во вкладку «Network» и нажмите «Ctrl + R».

Ручная проверка кодов ответа страниц в консолиРучная проверка кодов ответа страниц в консоли

Чтобы узнать код страницы, нужно смотреть столбец «Status».

Коды ответа сервера в столбце StatusКоды ответа сервера в столбце Status

Теперь о проверках с помощью сторонних сайтов и плагинов.

Bertal

Bertal — сервис для просмотра http-заголовков, веб-файлов (.html, .php, .asp, .gif, .jpg, .css и др.). Также позволяет просматривать html-код страниц. Работает с протоколами HTTP, HTTPS, FTP.

Возможности:

  • Запрос информации методами HEAD, GET, POST. Метод HEAD — если запрашивается заголовок. GET — если запрашивается заголовок и тело. POST — как и GET, но с заполненной строкой POST.
  • Поддерживаемые поисковые роботы: YandexBot, GoogleBot, BingBot, Yahoo, Baiduspider.
  • Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Internet Explorer, Opera, Opera mini.
  • Работает с Proxy.
  • Можно указывать содержимое Cookies.

Отчет по странице от BertalОтчет по странице от Bertal

Стоимость. Бесплатно.

PR-CY

PR-CY — cервис для SEO-аудита сайта, мониторинга и проверки позиций в поисковой выдачи. Подходит для анализа кодов ответа сервера, метатегов, содержимого страниц. Есть функции мониторинга сайта, проверки индексирования.

Возможности:

  • Проверка кодов ответа страниц. Сервис проверяет все элементы: текст, скрипты, видео, фотографии. После PR-CY дает рекомендации: сжать текст, сократить HTML, CSS или JS.
  • Работает с видами запросов: GET, POST, HEAD.
  • Глубокий анализ: проверка редиректов, поиск всех кодов.
  • Работает с поисковыми системами Google и Yandex.
  • Проверка контента: пустые заголовки, лишние скрипты, нерабочие внешние ссылки.

Еще у PR-CY есть много чего: проверка скорости загрузки, вирусов, срока действия SSL-сертификата и др.

Результаты анализа сайта в PR-CYРезультаты анализа сайта в PR-CY

Стоимость. Есть бесплатный тариф для экспресс-анализа сайта. Для полного аудита нужно покупать подписку. Она стартует от 990 ₽ в месяц. Позволяет вести до 5 проектов и проверять 1 000 страниц. Дорогие тарифы отличаются тем, что можно вести больше проектов и проверять больше страниц.

Читайте также: Как оптимизировать изображения для сайта

Checkmy

Checkmy — помогает проверить коды и заголовки ответа сервера. А еще доступность URL адресов, кеширование страниц, сжатие контента, исходный код, тип сервера и корректность переадресаций.

Возможности:

  • Работает с доменам на кириллице.
  • Работает через мобильную версию.
  • Проверяет страницы с несколькими редиректами.
  • Показывает размер и скорость загрузки страницы.
  • Проверяет контент на сжатие.

Проверка кодов ответа сервера через ChekmyПроверка кодов ответа сервера через Chekmy

Стоимость. Бесплатно.

Sitechecker

Sitechecker подходит для мониторинга сайта и полного аудита.  

Возможности:

  • Проверка состояния страницы и кодов ответа.
  • Подсчет «веса» HTML-кода страницы. Если он больше 2 Мб, сервис подскажет, как его уменьшить.
  • Отдельная проверка страницы с кодом 404.
  • Проверка индексации поисковыми системами.
  • SEO-анализ страницы: проверка title, description, заголовков h1-h6. Проверка изображений и атрибутов Alt, внутренних и внешних ссылок.
  • SEO-аудит сайта: оценка битых ссылок и редиректов, метатегов, скорости загрузки.
  • Мониторинг ресурса: контроль статуса индексирования, защита от взломов и отслеживание сайтов конкурентов.

Аудит сайта не сервисе SitechekerАудит сайта не сервисе Sitecheker

Стоимость. Можно сделать проверку кодов бесплатно. Но функции мониторинга, проверки обратных ссылок и индексации будут недоступны. Платная подписка стартует от 29 $ в месяц. Для подписки доступно 3 тарифа. Они отличаются количеством сайтов, которые можно проверять.

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

Яндекс.Вебмастер

Яндекс.Вебмастер поможет узнать, доступны ли страницы для поисковых роботов Яндекса. (Но ответ, полученный через Яндекс.Вебмастер, может отличаться от того, который получит поисковый робот. Дело в том, что инструмент работает через другой IP-адрес. Об этом сказано в Яндекс.Справке.)

Возможности:

  • Проверка всех классов ответа сервера.
  • Дополнительно можно узнать срок действия SSL-сертификата.
  • Проверяет страницы размером до 10 Мб.
  • Работает с файлами этих типов: PDF, DOC/DOCX, XLS/XLSX, PPT/PPTX, ODS, ODP, ODT, ODG, RTF, TXT и SWF.

Проверка ответа сервера через Яндекс.ВебмастерПроверка ответа сервера через Яндекс.Вебмастер

Стоимость. Бесплатно.

Converseo

Converseo подходит для как для проверки одиночного URL, так и для массового отслеживания.

Возможности:

  • Работа с методами GET, POST, HEAD.
  • Есть дополнительные функции: сравнение списков, загрузка фото из Instagram.
  • Готовый отчет можно скачать в формате CSV.

Вот так выглядит отчет по массовой проверке URL на сайте Converseo.Вот так выглядит отчет по массовой проверке URL на сайте Converseo.

Вот так выглядит отчет по одиночной проверке URL на сайте Converseo.Вот так выглядит отчет по одиночной проверке URL на сайте Converseo.

Стоимость. Бесплатно.

Coolakov

Coolakov — работает также, как и Converseo. Есть и дополнительные функции.

Возможности:

  • Массовая проверка URL. Особенность в том, что выдается конечный ответ сервера. Например, если был редирект на рабочую страницу — ответ будет 200. Если на сломанную — в зависимости от ошибки.
  • Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Safari.
  • Проверка доступности сайта.
  • Измерение скорости загрузки портала.
  • Проверка индекса качества сайта.
  • Проверка орфографии.

Проверка ответов сервера через CoolakovПроверка ответов сервера через Coolakov

Стоимость. Бесплатно.

Headmasterseo

Headmasterseo. Программа для Windows и Mac, которая проверяет массовые URL. Отслеживает коды состояния, редиректы, время ответа и заголовки ответов.

Возможности:

  • Проверка URL с помощью метода HEAD.
  • Одновременная проверка 500 ссылок.
  • Проверка циклов перенаправления. Есть тестер, который оценит, правильно ли настроен редирект.
  • Работает с прокси.
  • Готовый отчет можно экспортировать в формате CSV.
  • Проверка полей заголовков.
  • Проверка Sitemap файлов в формате XML.

Пример отчета в HeadmasterseoПример отчета в Headmasterseo

Стоимость. До 500 URL можно проверять бесплатно. Чтобы проверить больше, нужно платить. За 10 000 URL придется заплатить 50 $. За 100 000 — 100 $. Неограниченное количество ссылок можно проверять за 150 $.

Читайте также: Исчерпывающий гид по поисковым операторам Google и Яндекса

Плагины

Redirect Path Link. Это бесплатный плагин для Google Chrome. Он поможет провести SEO-аудит сайта и проверить HTTP-заголовки. Работает только с 3 классом кодов сервера. 

Robots Exclusion Checker. Помогает оптимизировать сайт, найти проблемы в индексации и сделать SEO-аудит. Плагин бесплатный. Работает со всеми классами кодов и поисковыми роботами Googlebot, Bing, Yahoo.

SEO META in 1 CLICK. Бесплатный плагин для Google Chrome. Помогает проверить коды ответа сервера, проанализировать заголовки H1-H6, проверить изображения и Alt атрибуты к ним и др. 

Website SEO Checker: Free Audit & Analysis. Бесплатный плагин от Sitecheker. В нем есть такие же функции, как и на сайте: аудит, мониторинг, анализ, просмотр кодов ответа и т.д.

Коротко о главном

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

  1. 1ХХ — информационные.
  2. 2ХХ — успешные.
  3. 3ХХ — переадресация
  4. 4ХХ — проблемы со стороны пользователя.
  5. 5ХХ — проблемы со стороны сервера.

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

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

А чтобы глубже разобраться в SEO, приходите учиться в CyberMarketing. У нас есть статьи, вебинары, базовые и продвинутые курсы по поисковому продвижению. Преподают эксперты Promopult: Руслан Байбеков и Евгений Костин.

Источник

Возможно, вам также будет интересно:

  • Как показать прошлого года ошибки
  • Как полностью проверить компьютер на ошибки windows 10
  • Как полностью проверить компьютер на наличие ошибок
  • Как показать ошибку на форме
  • Как показывать ошибки php ubuntu

    • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии