Содержание

Проверка ответа сайта и загрузки страницы

Тип запроса к серверу

GETPOSTHEAD

Максимальное время загрузки данных*

Параметры для POST-запроса

Сервера для проверки Вашего сайта:

сервер Россия (Москва)

сервер Россия (Санкт-Петербург)

сервер Россия (Новосибирск)

Выбранная страница сайта скачивается на сервера мониторингов по HTTP/HTTPS.

Проверяется скорость загрузки кода страницы или заголовка ответа.

На сервер не скачиваются картинки и дополнительные скрипты, а только код выбранной страницы.

Другие проверки Выберите чтобы перейти к проверке————————————————————Комплексная проверка сайта————————————————————Проверка доступности сайта PINGПроверка загрузки страницы HTTP/HTTPSПроверка ответа от DNSПроверка доменаПроверка сертификатаПроверка сайта на вирусыПроверка доступности FTPПроверка произвольного порта

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

Для того, чтобы статистика о Вашем ресурсе собиралась постоянно — запустите постоянный мониторинг

ЗАПУСТИТЬ ПОСТОЯННЫЙ МОНИТОРИНГ БЕСПЛАТНО!

Для новых пользователей бесплатный мониторинг одного сайта — 15 дней!

Анализ сайта

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

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

Причины медленной загрузки сайта

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

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

Настройка параметров мониторинга

Вам необходимо выбрать тип запроса к серверу:

  • GET

    скачивание указанной страницы, с переданными параметрами в строке запроса

  • POST

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

  • HEAD

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

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

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

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

Но лучше указывать конечную правильную страницу, с правильным протоколом (http или https).

Основные причины необходимости проверок HTTP/HTTPS:

Проверка ответа сервера

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

Работоспособность сайта

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

Проверка загрузки страницы и ответа сервера — основной метод мониторинга работоспособности сайтов

Если необходимо проверить нестандартный порт сервера — проверить порт

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

monitor-site.com

Коды состояния http | Wiki — PeterHost

Wiki Коды состояния http

Категория:Виртуальный хостинг -> Инструкции -> Разное

Содержание

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

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 15 May 2010 06:04:26 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Content-Length: 6426
Expires: Sat May 15 06:04:26 2010 GMT
Last-Modified: Sat May 15 06:04:26 2010 GMT
Set-Cookie: S=; path=/; expires=Wed, 17-May-2000 06:04:26 GMT
Set-Cookie: S=; domain=.ya.ru; path=/; expires=Wed, 17-May-2000 06:04:26 GMT
X-XRDS-Location: http://openid.yandex.ru/server_xrds/

<html>
<head>
<meta http-equiv=«Content-Type«content=«text/html;charset=utf-8»>
<title>Яндекс</title>
<link rel=«shortcut icon«href=«http://yandex.st/lego/2.2.8/common/block/b-service-icon/_ico/b-service-icon_serp.ico»><base target=»_top»>


…
</body>
</html>

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

Классы кодов ответа:

1xx Informational ( Информационный)

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

2xx Success (Успешно)

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

3xx Redirection (Перенаправление)

Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другой ссылке). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location.

Узнать код ответа сервера на определенный запрос можно с помощью утилиты curl, вызвав её с ключом -I.
Команду curl можно использовать из командной строки *nix-подобной операционной системы, например, зайдя на сервер по SSH.
Запросим с помощью неё yandex.ru:

curl -I http://yandex.ru

и получим следующий ответ:

HTTP/1.1 301 Moved Permanently
Date: Sat, 15 May 2010 05:39:40 GMT
Server: Apache/2.2.9 (Unix) mod_perl/2.0.4 Perl/v5.8.8
Location: http://www.yandex.ru/
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=iso-8859-1

Сервер яндекса на запрос yandex.ru ответил кодом «301 Moved Permanently», что, как сказано выше, означает необходимость выполнить запрос по предложенному сервером адресу(этот адрес указан в заголовке «Location», и в данном случае это www.yandex.ru).
Сервер сообщает нам, что обращаться нужно не к yandex.ru, а к www.yandex.ru.

Запросим www.yandex.ru:

curl -I http://www.yandex.ru

получим ответ:

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 15 May 2010 06:01:26 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Content-Length: 73507
Expires: Sat May 15 06:01:27 2010 GMT
Last-Modified: Sat May 15 06:01:27 2010 GMT
Set-Cookie: S=; path=/; expires=Wed, 17-May-2000 06:01:26 GMT
Set-Cookie: S=; domain=.yandex.ru; path=/; expires=Wed, 17-May-2000 06:01:26 GMT
Set-Cookie: yandexuid=3572906971273903287; domain=.yandex.ru; path=/; expires=Tue, 12-May-2020 06:01:26 GMT
X-XRDS-Location: http://openid.yandex.ru/server_xrds/

Код ответа «200 OK». Сервер исправно выполнил запрос и вернул пользователю результат.

4xx Client Error (Ошибка клиента)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента.

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

Запрос не принят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

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

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

curl -I http://monitoring.z8.ru

сервер ответит, что не выдаст результат, пока не будут предоставлены логин/пароль:

HTTP/1.1 401 Authorization Required
Server: nginx/0.5.7
Date: Sat, 15 May 2010 06:16:23 GMT
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
WWW-Authenticate: Basic realm="Nagios Access"
403 Forbidden (Запрещено)

Сервер вернул ошибку 403 при попытке просмотра директории доступ к которой был запрещён. Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе со стороны клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401. В противном случае ограничения были заданы администратором сервера или разработчиком web-приложения и могут быть любыми в зависимости от возможностей используемого ПО. Наиболее вероятными причинами ограничения могут являться:

  • Попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью настроек доступа к серверу.
  • Для доступа требуется аутентификация не средствами HTTP (например, для доступа к CMS или разделу для зарегистрированных пользователей).
  • Сервер не удовлетворён IP-адресом клиента (например, временная блокировка из-за частых обращений или же на этапе разработки приложения доступ разрешён только некоторым IP).
  • В запрашиваемой директории отсутствует индексный файл.
404 Not Found (Не найдено)

Сервер понял запрос, но не нашёл соответствующего ресурса по указанной ссылке. Запросим несуществующую страницу:

curl -I http://yandex.ru/instr/index.php

И получим ответ 404:

HTTP/1.1 404 Not Found
Date: Sat, 15 May 2010 06:56:24 GMT
Server: Apache/2.2.9 (Unix) mod_perl/2.0.4 Perl/v5.8.8
Accept-Ranges: bytes
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
405 Method Not Allowed (Метод не применим)

Указанный клиентом метод запроса нельзя применить к текущему ресурсу.

499 Client Closed Request (Nginx)

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

5xx Server Error (Ошибка сервера)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.

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

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx. В основном может возникать в случаях:

  • ошибок пользователей в файле .htaccess.
  • ошибок в скриптах пользователя.
  • проблем на сервере
502 Bad Gateway (Плохой шлюз)

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

503 Service Unavailable (Сервис недоступен)

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

504 Gateway Timeout (Шлюз не отвечает)

См. 502

Категории:

peterhost.ru

HTTP ответы сервера: строка состояния HTTP ответа, коды состояния, заголовки HTTP ответа, примеры

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы с тобой разберем, как отвечает HTTP сервер на запросы клиента. Как всегда: понятно и с примерами, но если тебе что-то будет непонятно — не стесняйся спросить в комментариях. Ответ ты получишь, как минимум, HTTP. Как ты уже догадался, в этой записи мы с тобой будем говорить про HTTP ответы сервера, а конкретнее: про строку состояния HTTP ответа сервера, немного поговорим про коды состояния HTTP ответа, посмотрим какие заголовки сервер может посылать в ответ на запрос и разберем несколько примеров HTTP ответа сервера.

HTTP ответы сервера: строка состояния HTTP ответа, коды состояния, заголовки HTTP ответа, примеры

Структура HTTP ответа сервера

Содержание статьи:

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. HTTP ответы – это HTTP сообщение, которое посылает сервер в ответ на запрос клиента. Ответы HTTP сервера строго регламентированы и имеют четкую структуру. Структура HTTP ответа сервера состоит из:

  1. Строки состояния HTTP ответа, в которой сервер указывает версию HTTP протокола и код состояния.
  2. Нуля или нескольких полей HTTP заголовка, разделенных между собой символом CRLF.
  3. Пустой строки (в этой строке должен быть только символ CRLF), эта строка обозначает окончание полей заголовка.
  4. Необязательное тело HTTP сообщения.

Для тех кому непонятно словесное описание структуры HTTP ответа сервера приведем пример:

Response      = Status-Line               ; *( general-header         ; | response-header        ; | entity-header )        ; CRLF [ message-body ]          ;

Response      = Status-Line               ;

 

*( general-header         ;

 

| response-header        ;

 

| entity-header )        ;

 

CRLF

 

[ message-body ]          ;

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

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

Первая строка в HTTP ответе – это строка состояния, иначе Status-Line. Она состоит из версии протокола HTTP, числового кода состояния HTTP сервера и поясняющей фразы. Окончание строки состояния в HTTP ответе является символ CRLF. Пример строки состояния HTTP ответа сервера:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Вот таким нехитрым образом записывается строка состояния в HTTP ответ. Да, кстати, строка состояния — это параметр HTTP.

Код состояния HTTP ответа и поясняющая фраза

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

Вообще, правильно говорить элемент кода состояния или Status-Code – это целочисленный трехразрядный код результата понимания и удовлетворения запроса клиента. Грубо говоря, это число, которое показывает то, как сервер понял запрос клиента. К коду состояния HTTP ответа идет поясняющая фраз, которая предназначена для людей, чтобы те понимали, что в итоге случилось. Давайте сведем в таблицу коды состояний  HTTP сервера и дадим к ним пояснения:

НомерКод состояния HTTP сервера и его описание
11xx: информационный код состояния HTTP сервера Все коды состояний, начинающиеся с единицы говорят клиенту о том, что их запрос получен и находится в обработке  и называются они — информационные коды состояния.
22xx: успешный код состояния HTTP сервера Все коды состояний, начинающиеся с двойки говорят клиенту о том, что действие закончилось успешно: получено, понято и обработано, такие коды называются успешные HTTP коды.
33xx: код перенаправления HTTP сервера Все коды состояния, начинающиеся с тройки говорят клиенту о том, что для продолжения работы ему нужно совершить какие-то действия, это коды получили название кодов перенаправления HTTP сервера.
44xx: коды ошибок HTTP клиента Все коды состояния, начинающиеся с четверки говорят нам о том, что ошибка происходит по вине клиента (неверный синтаксис, устаревший протокол и прочее), из-за чего сервер не может корректно отработать и дать ответ. Их называют коды ошибок HTTP клиента.
55xx: коды ошибок HTTP сервера Все коды состояний, начинающиеся с пятерки, говорят нам о том, что произошла ошибка на стороне сервера HTTP. И они получили называние коды ошибок HTTP сервера.

 

Приведем набор кодов состояний в HTTP и поясняющие фразы к ним:

Status-Code    = «100»   ; Продолжать, Continue | «101»   ; Переключение протоколов, ; Switching Protocols | «200»   ; OK | «201»   ; Создан, Created | «202»   ; Принято, Accepted | «203»   ; Не авторская информация, ; Non-Authoritative Information | «204»   ; Нет содержимого, No Content | «205»   ; Сбросить содержимое, Reset ; Content | «206»   ; Частичное содержимое, Partial ; Content | «300»   ; Множественный выбор, Multiple ; Choices | «301»   ; Постоянно перенесен, Moved ; Permanently | «302»   ; Временно перемещен, Moved ; Temporarily | «303»   ; Смотреть другой, See Other | «304»   ; Не модифицирован, Not Modified | «305»   ; Используйте прокси-сервер, Use ; Proxy | «400»   ; Испорченный Запрос, Bad Request | «401»   ; Несанкционированно, Unauthorized | «402»   ; Требуется оплата, Payment ; Required | «403»   ; Запрещено, Forbidden | «404»   ; Не найден, Not Found | «405»   ; Метод не дозволен, Method Not ; Allowed | «406»   ; Не приемлем, Not Acceptable | «407»   ; Требуется установление ; подлинности через прокси-сервер, ; Proxy Authentication Required | «408»   ; Истекло время ожидания запроса, ; Request Timeout | «409»   ; Конфликт, Conflict | «410»   ; Удален, Gone | «411»   ; Требуется длина, Length Required | «412»   ; Предусловие неверно, ; Precondition Failed | «413»   ; Объект запроса слишком большой, ; Request Entity Too Large | «414»   ; URI запроса слишком длинный, ; Request-URI Too Long | «415»   ; Неподдерживаемый медиа тип, ; Unsupported Media Type | «500»   ; Внутренняя ошибка сервера, ; Internal Server Error | «501»   ; Не реализовано, Not Implemented | «502»   ; Ошибка шлюза, Bad Gateway | «503»   ; Сервис недоступен, Service ; Unavailable | «504»   ; Истекло время ожидания от шлюза, ; Gateway Timeout | «505»   ; Не поддерживаемая версия HTTP, ; HTTP Version Not Supported | extension-code   extension-code = 3DIGIT   Reason-Phrase  = *<TEXT не включающий CR, LF>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

Status-Code    = «100»   ; Продолжать, Continue

 

| «101»   ; Переключение протоколов,

 

; Switching Protocols

 

| «200»   ; OK

 

| «201»   ; Создан, Created

 

| «202»   ; Принято, Accepted

 

| «203»   ; Не авторская информация,

 

; Non-Authoritative Information

 

| «204»   ; Нет содержимого, No Content

 

| «205»   ; Сбросить содержимое, Reset

 

; Content

 

| «206»   ; Частичное содержимое, Partial

 

; Content

 

| «300»   ; Множественный выбор, Multiple

 

; Choices

 

| «301»   ; Постоянно перенесен, Moved

 

; Permanently

 

| «302»   ; Временно перемещен, Moved

 

; Temporarily

 

| «303»   ; Смотреть другой, See Other

 

| «304»   ; Не модифицирован, Not Modified

 

| «305»   ; Используйте прокси-сервер, Use

 

; Proxy

 

| «400»   ; Испорченный Запрос, Bad Request

 

| «401»   ; Несанкционированно, Unauthorized

 

| «402»   ; Требуется оплата, Payment

 

; Required

 

| «403»   ; Запрещено, Forbidden

 

| «404»   ; Не найден, Not Found

 

| «405»   ; Метод не дозволен, Method Not

 

; Allowed

 

| «406»   ; Не приемлем, Not Acceptable

 

| «407»   ; Требуется установление

 

; подлинности через прокси-сервер,

 

; Proxy Authentication Required

 

| «408»   ; Истекло время ожидания запроса,

 

; Request Timeout

 

| «409»   ; Конфликт, Conflict

 

| «410»   ; Удален, Gone

 

| «411»   ; Требуется длина, Length Required

 

| «412»   ; Предусловие неверно,

 

; Precondition Failed

 

| «413»   ; Объект запроса слишком большой,

 

; Request Entity Too Large

 

| «414»   ; URI запроса слишком длинный,

 

; Request-URI Too Long

 

| «415»   ; Неподдерживаемый медиа тип,

 

; Unsupported Media Type

 

| «500»   ; Внутренняя ошибка сервера,

 

; Internal Server Error

 

| «501»   ; Не реализовано, Not Implemented

 

| «502»   ; Ошибка шлюза, Bad Gateway

 

| «503»   ; Сервис недоступен, Service

 

; Unavailable

 

| «504»   ; Истекло время ожидания от шлюза,

 

; Gateway Timeout

 

| «505»   ; Не поддерживаемая версия HTTP,

 

; HTTP Version Not Supported

 

| extension-code

 

 

 

extension-code = 3DIGIT

 

 

 

Reason-Phrase  = *<TEXT не включающий CR, LF>

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

Поля заголовка HTTP ответа

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

response-header = Age                     ; | Location                ; | Proxy-Authenticate      ; | Public                  ; | Retry-After             ; | Server                  ; | Vary                    ; | Warning                 ; | WWW-Authenticate        ;

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

response-header = Age                     ;

 

| Location                ;

 

| Proxy-Authenticate      ;

 

| Public                  ;

 

| Retry-After             ;

 

| Server                  ;

 

| Vary                    ;

 

| Warning                 ;

 

| WWW-Authenticate        ;

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

Пример HTTP ответа сервера

Давайте теперь посмотрим пример HTTP ответа сервера, помните, мы запрашивали у сервера HTML документ в записи про HTTP запросы? Давайте теперь посмотрим, какой ответ нам даст HTTP сервер:

HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache/2.2.14 (Win32) Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT Content-Length: 88 Content-Type: text/html Connection: Closed <html> <body> <h2>Hello, World!</h2> </body> </html>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

HTTP/1.1 200 OK

 

Date: Mon, 27 Jul 2009 12:28:53 GMT

 

Server: Apache/2.2.14 (Win32)

 

Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT

 

Content-Length: 88

 

Content-Type: text/html

 

Connection: Closed

 

<html>

 

<body>

 

<h2>Hello, World!</h2>

 

</body>

 

</html>

А теперь давайте посмотрим, какой ответ нам даст HTTP сервер, если произойдет ошибка и сервер не сможет найти требуемую нам страницу:

HTTP/1.1 404 Not Found Date: Sun, 18 Oct 2012 10:36:20 GMT Server: Apache/2.2.14 (Win32) Content-Length: 230 Connection: Closed Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC «-//IETF//DTD HTML 2.0//EN»> <html> <head> <title>404 Not Found</title> </head> <body> <h2>Not Found</h2> <p>The requested URL /t.html was not found on this server.</p> </body> </html>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

HTTP/1.1 404 Not Found

 

Date: Sun, 18 Oct 2012 10:36:20 GMT

 

Server: Apache/2.2.14 (Win32)

 

Content-Length: 230

 

Connection: Closed

 

Content-Type: text/html; charset=iso-8859-1

 

<!DOCTYPE HTML PUBLIC «-//IETF//DTD HTML 2.0//EN»>

 

<html>

 

<head>

 

<title>404 Not Found</title>

 

</head>

 

<body>

 

<h2>Not Found</h2>

 

<p>The requested URL /t.html was not found on this server.</p>

 

</body>

 

</html>

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

HTTP/1.1 400 Bad Request Date: Sun, 18 Oct 2012 10:36:20 GMT Server: Apache/2.2.14 (Win32) Content-Length: 230 Content-Type: text/html; charset=iso-8859-1 Connection: Closed   <!DOCTYPE HTML PUBLIC «-//IETF//DTD HTML 2.0//EN»> <html> <head> <title>400 Bad Request</title> </head> <body> <h2>Bad Request</h2> <p>Your browser sent a request that this server could not understand.</p> <p>The request line contained invalid characters following the protocol string.</p> </body> </html>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

HTTP/1.1 400 Bad Request

 

Date: Sun, 18 Oct 2012 10:36:20 GMT

 

Server: Apache/2.2.14 (Win32)

 

Content-Length: 230

 

Content-Type: text/html; charset=iso-8859-1

 

Connection: Closed

 

 

 

<!DOCTYPE HTML PUBLIC «-//IETF//DTD HTML 2.0//EN»>

 

<html>

 

<head>

 

<title>400 Bad Request</title>

 

</head>

 

<body>

 

<h2>Bad Request</h2>

 

<p>Your browser sent a request that this server could not understand.</p>

 

<p>The request line contained invalid characters following the protocol string.</p>

 

</body>

 

</html>

Вот так легко и просто мы разобрались с HTTP ответами сервера.

zametkinapolyah.ru

Код ответа сервера, коды ответов HTTP

Код ответа сервера — информация, возвращаемая клиенту, выполнившему HTTP запрос к  серверу, доступному в сети. Запрос выполняется к определенному серверу и определенному порту. Если рассматривать веб-сервер, обращение идет по IP адресу на порт 80 или 443 (в зависимости от протокола: http или https).

Запросы бывают различных типов, запросы на получение данных — это обычно GET. HEAD запросы предназначены для того чтобы получить только заголовки.

 

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

Проверка ответа сервера  — telnet

telnet 123.123.123.123 80

Trying ::1…
Connected to localhost.
Escape character is ‘^]’.

 

GET / HTTP/1.1

Host: example.com

 

Теперь дважды нужно нажать Enter на клавиатуре

В консоль будет выведен HTTP ответ — в нем интерес представляет первая строка, а которой и содержится нужная информация

 

HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Thu, 01 Mar 2018 16:26:59 GMT
Content-Type: text/html
Content-Length: 612
…

 

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

Проверка ответа сервера — curl

curl лучше всего использовать с ключем -I, в этом случае отдаваться будут только заголовки без содержимого страницы, что и требуется. Запросим домен server-gu.ru

curl -I server-gu.ru

HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.3
Date: Thu, 01 Mar 2018 16:46:19 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://server-gu.ru/

 

Если выполнить запрос к сайту с https ответ будет 200.

curl -I https://server-gu.ru

 

Коды ответа сервера, которые можно встретить чаще всего:
  • 200 — запрос успешно обработан
  • 301 — постоянный редирект на другой домен
  • 302 — некэширующийся редирект (подробнее о различиях)
  • 404 — страница не найдена
  • 403 — доступ запрещен
  • 500 — ошибка сервера, вызванная неверной настройкой (подробнее)
  • 502 — ошибка сервера, вызванная отсутствием ответа от бэкенда (подробнее)

 

Все коды, начинающиеся на 2хх означают, что запрос успешно обработан, на 3хх, что выполняется переадресация,  на 4хх — произошла ошибка на стороне клиента, на 5хх — произошла ошибка на стороне сервера.

 

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

server-gu.ru

HTTP | Все коды ошибок

Во время запроса информации с удаленного веб сервера может возникнуть ошибка, тогда веб-сервер посылает в ответ код ошибки HTTP. Например 404 – Not Found (ресурс не найден).
Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

Введите в поле ниже интересующий Вас трех символьный код и получите его описание:

100

ContinueCервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101

Switching ProtocolsСервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовкаUpdate. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

102

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

200

ОКУспешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201

CreatedВ результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется[источник не указан 336 дней] ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202

AcceptedЗапрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203

Non-Authoritative InformationАналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204

No ContentСервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205

Reset ContentСервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206

Partial ContentСервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)

207

Multi-StatusСервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226

IM Used Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

300

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

301

Moved PermanentlyЗапрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302

Found, Moved TemporarilyЗапрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, приуправляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303

See OtherДокумент по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304

Not ModifiedСервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305

Use ProxyЗапрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306

(зарезервировано)использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307

Temporary RedirectЗапрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

400

Bad RequestСервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401

UnauthorizedДля доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402

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

403

ForbiddenСервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404

Not FoundСамая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405

Method Not AllowedУказанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406

Not AcceptableЗапрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407

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

408

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

409

ConflictЗапрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410

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

411

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

412

Precondition FailedВозвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

413

Request Entity Too LargeВозвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414

Request-URL Too LongСервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415

Unsupported Media TypeПо каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416

Requested Range Not SatisfiablВ поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

417

Expectation FailedПо каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

422

Unprocessable EntityСервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423

LockedЦелевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424

Failed DependencyРеализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425

Unordered Collection —Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol[14].

426

Upgrade RequiredСервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено вRFC 2817 для возможности перехода к TLS посредством HTTP.

449

Retry WithВозвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

456

Unrecoverable ErrorВозвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

500

Internal Server ErrorЛюбая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501

Not ImplementedСервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502

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

503

Service UnavailableСервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504

Gateway TimeoutСервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505

HTTP Version Not SupportedСервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506

Variant Also NegotiatesВ результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507

Insufficient StorageНе хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

509

Bandwidth Limit ExceededИспользуется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510

Not ExtendedНа сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

allerrorcodes.ru

Проверка ответа сервера, HTTP-заголовки сервера

Список заголовков HTTP

Список кодов состояния HTTP

Код состояния HTTP (англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).

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

Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе «Коды состояния служб IIS» в Базе знаний Microsoft.

1xx: Informational (Информационные)

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

100 Continue (Продолжать) — Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101 Switching Protocols (Переключение протоколов) — Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing (Идёт обработка) — Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) — При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

2xx: Success (Успешно)

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

200 OK (Хорошо) — Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201 Created (Создано) — В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202 Accepted (Принято) — Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203 Non-Authoritative Information (Информация не авторитетна) — Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204 No Content (Нет содержимого) — Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205 Reset Content (Сбросить содержимое) — Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206 Partial Content (Частичное содержимое) — Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.

207 Multi-Status (Многостатусный) — Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226 IM Used (Использовано IM) — Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Redirection (Перенаправление)

Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

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

Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды 303 и 307 вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

300 Multiple Choices (Несколько вариантов выбора) — По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301 Moved Permanently (Перемещено навсегда) — Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302 Moved Temporarily / Found (Перемещено временно / Найдено) — Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303 See Other (Смотреть другое) — Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304 Not Modified (Не изменялось) — Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305 Use Proxy (Использовать прокси) — Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306 (Зарезервировано, код использовался только в ранних спецификациях) — Использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307 Temporary Redirect (Временное перенаправление) — Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx: Client Error (Ошибка клиента)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request (Плохой запрос) — Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401 Unauthorized (Неавторизован) — Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

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

403 Forbidden (Запрещено) — Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404 Not Found (Не найдено) — Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405 Method Not Allowed (Метод не поддерживается) — Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406 Not Acceptable (Неприемлемо) — Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407 Proxy Authentication Required (Необходима прокси авторизация) — Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408 Request Timeout (Истекло время ожидания) — Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409 Conflict (Конфликт) — Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

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

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

412 Precondition Failed (Условие ложно) — Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.

413 Request Entity Too Large (Размер запроса слишком велик) — Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414 Request-URI Too Large (Запрашиваемый URI слишком длинный) — Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415 Unsupported Media Type (Неподдерживаемый тип данных) — По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).

417 Expectation Failed (Ожидаемое неприемлемо) — По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

418 I’m a teapot (Я — чайник) — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.

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

423 Locked (Заблокировано) — Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424 Failed Dependency (Невыполненная зависимость) — Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425 Unordered Collection (Неупорядоченный набор) — используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.

426 Upgrade Required (Необходимо обновление) — Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

428 Precondition Required (Необходимо предусловие) — Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.

429 Too Many Requests (Слишком много запросов) — Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.

431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.

434 Requested host unavailable. (Запрашиваемый адрес недоступен) — Запрашиваемый адрес недоступен.

449 Retry With (Повторить с) — Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) — Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».

456 Unrecoverable Error (Некорректируемая ошибка) — Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 () — Используется Nginx, когда клиент закрывает соединение до получения ответа.

5xx: Server Error (Ошибка сервера)

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

500 Internal Server Error (Внутренняя ошибка сервера) — Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501 Not Implemented (Не реализовано) — Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502 Bad Gateway (Плохой, ошибочный шлюз) — Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503 Service Unavailable (Сервис недоступен) — Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504 Gateway Timeout (Шлюз не отвечает) — Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505 HTTP Version Not Supported (Версия HTTP не поддерживается) — Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506 Variant Also Negotiates (Вариант тоже проводит согласование) — В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage (Переполнение хранилища) — Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

508 Loop Detected (Обнаружена петля) —

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) — Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510 Not Extended (Нет расширения) — На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

511 Network Authentication Required (Требуется сетевая аутентификация) — Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

tools.seo-auditor.com.ru

Проверка кода ответа сервера: коды статусов HTTP, сервисы

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

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

Содержание статьи:

Популярные коды статусов HTTP

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

  • 200 OK — запрос выполнен успешно. Если у вас при проверке отображается код ответа сервера 200, значит с этой страницей все хорошо.
  • 301 Moved Permanently — мы уже встречались с этим вариантом в статье про 301 редирект. Он означает, что страница навсегда перемещена на другой адрес (URL). При этом передается почти весь ссылочный вес.
  • 302 Moved Temporarily — запрашивая страница временно доступна по другому адресу.
  • 404 Not Found — по указанному УРЛу ничего не найдено. Желательно создать на своем сайте эффективную страницу 404 ошибки, где пользователю отображалась бы соответствующая информация и рекомендации.
  • 403 Forbidden — ограничение прав доступа к конкретной странице. Администратор сайта может специально закрыть от пользователей системные файлы или директории. Также это может свидетельствовать об ошибке установки прав на папку. Если для доступа к странице нужна аутентификация, то используется код статуса HTTP 401 Unauthorized.
  • 408 Request Timeout — истекло время ожидания сервером. Бывает при загрузке пользователем слишком объемного файла на сайт.
  • 500 Internal Server Error — код ответа сервера 500 означает любую ошибку, не описанную в других статусах 5xx.
  • 502 Bad Gateway — свидетельствует о проблемах в работе сервера DNS, прокси или хостинг провайдера. Обычно траблы возникают с последним — можете смело писать в тех.поддержку и спрашивать почему не работает сайт.
  • 503 Service Unavailable — данный код означает, что сервер недоступен по техническим причинам (будь то перегрузка или отключение на тех.обслуживание). С помощью параметра Retry-After можно указать рекомендуемое время повторения запроса. В любом случае поисковые роботы позже еще зайдут на ваш сайт.
  • 504 Gateway Timeout — сервер не успел вернуть ответ в определенный лимит времени. Обычно это случается при резких больших нагрузках на сайт, к которым ваш хостинг не готов. Как вариант решения — купить сервер помощнее.

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

Методы проверки ответа сервера

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

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

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

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

Сервисы проверки ответа сервера

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

PR-CY

Среди множества SEO инструментов портала PR-CY нашлась нужная нам функция проверки заголовков сервера. Кроме самого статуса выводится некоторая дополнительная информация.

Checkmy

Онлайн сервис специально создан для определения кода ответа сервера. Поддерживается gzip сжатие, кириллические домены, имеется выбор User Agent’а, а также мобильная версия. Выглядит симпатично.

Mainspy

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

HTTP Status Code Checker

Англоязычных сервисов, где можно проверить ответ сервера еще больше. Один из первых в выдаче — httpstatus.io. Тут все предельно просто: вводите адрес страницы, выбираете (если нужно) дополнительные параметры запроса и кликаете Submit.

Server Headers Checker

Очень часто функцию проверки HTTP кода состояния страниц можно встретить на тематических SEOшных порталах или даже блогах. Инструменты от Seobook — отличный тому пример. Особенностью сервиса есть возможность исследования сразу нескольких страниц.

Netpeak Spider — программа проверки ответа сервера

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

В отличии от большинства предыдущих онлайн сервисов программа позволяет оценить сразу множество страниц. Удобно для анализа своего сайта, однако не уверен, что она сможет «обработать» набор разных URL’ов из заданного списка. Скачавайте ее тут. Распространяется бесплатно.

HEADMasterSEO

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

Софт позволяет получить статусы ответов сервера для большого списка линков, а также считывает ряд других параметров: редиректы, время отклика, ссылки в head, X-Robots-Tag и т.п. Результаты можно сортировать, фильтровать и экспортировать в CSV. Работает программа под Windows и Mac OS X. Честно, не совсем понимаю, что значит ограничее 500 урлов «за одну операцию» — если допускается повторный запуск программы с новыми ссылками, то это безусловно удобнее чем юзать Tor для онлайн чекеров или запускать по 50 линков.

Массовая проверка ответа сервера

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

Из наших нашел всего парочку более-менее нормальных сервисов, лучший из них — чекер от Dimax.biz.

Backlinks Checker Dimax.biz

Он предоставляет наиболее точные результаты по кодам ответа сервера. К сожалению, есть ограничение на число проверок — в сутки с одного IP-адреса можно сделать 2 запроса по 50 линков каждый. Для бОльших объемов придется купить PRO-аккаунт.

HTTP status code checker tool

Удобно, что данный проект кроме английского имеет локализацию интерфейса на русском и нескольких других языках. Над формой проверки найдете небольшое пояснение по кодам состояния HTTP и работе самого сайта. Ограничений не заметил, для удобства статус подсвечивается цветом: зеленый — все ок, черный или красный — проблемный URL.

Bulk Server Response Checker w/ Export

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

Urlitor

По функциональности все англоязычные сервисы также простые и, в принципе, одинаковые. Есть поле для ввода проверяемых ссылок и (в некоторых случаях) выбор User-Agent. В буржуйских проектах мне нравится, что все результаты представлены в виде таблиц для более легкого восприятия. Хотя у Dimax.biz ссылки сразу сортируются в зависимости от кода ответа сервера, что также удобно. Плюсом Urlitor можно назвать наличие активных ссылок в результатах — вы сможете быстро перейти по тем или иным линкам.

Bulk Redirect Checker Tool

Если я правильно понял, то основная задача данного сервиса — определение редиректов в зависимости от используемого User-Agent (браузера). Хотя при этом он показывает и коды HTTP статусов. Минимум дизайна, результаты отображаются достаточно быстро.

Итого. Использование тех или иных инструментов проверки ответа сервера зависит от вашей задачи. Проанализировать конкретные линки со своего сайта поможет Яндекс.Вебмастер, узнать информацию по всем страницам позволяет Netpeak Spider. Онлайн сервисы решают задачу, если нужно проверить HTTP состояние одной или множества страниц не ваших проектов.

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

tods-blog.com.ua

No related posts.

Добавить комментарий

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