Как проверить ответ сервера
Когда мы открываем любую веб-страницу нужного нам сайта вместе с 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 заголовки?
С помощью 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.ru
Или, если хотите, чтобы ответ выглядел более естественно:
curl -I https://losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2
Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:
curl -I http://losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2
curl -I https://www.losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2
Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.
Проверка http заголовков с помощью Curl
Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:
curl -I https://losst.ru
Здесь отображается код ответа сервера, а также принятые 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.ru/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.ru
Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:
curl -I --header 'If-Modified-Since: Mon, 26 Dec 2016 18:13:12 GMT' https://losst.ru
В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.
Проверка If-None-Match
Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:
curl -I https://losst.ru
Затем отправим полученную сумму с заголовком:
curl -I --header 'If-None-Match: "58615db8-19034"' https://losst.ru
И снова мы должны получить ответ 304, страница не изменена.
Проверка сжатия
Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:
curl -I https://losst.ru --header 'Accept-Encoding: gzip'
В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.
Выводы
В этой статье мы рассмотрели как выполняется проверка ответа сервера и проверка http заголовков, это может быть очень полезно для аудита технической стороны вашего сайта, а также для решения определенных проблем. Надеюсь, изложенная в статье информация была вам полезной.
losst.ru
От чего зависит время ответа сервера
Скорость ответа сайта зависит от того, насколько быстро сервер обработает запрос и вернет результат. Основная причина слишком медленной реакции сайта — это перегрузка. Сервер не справляется с тем количеством запросов, которое к нему поступает. Чтобы уменьшить время ответа, нужно либо улучшить конфигурацию сервера, либо оптимизировать скрипты и запросы к базе данных. После такой оптимизации сервер будет тратить меньше времени на один запрос и успеет обрабатывать больше количество запросов за единицу времени.
Не существует универсального способа сократить время ответа сервера. В каждом случае должен быть индивидуальный подход к оптимизации нагрузки.
Нормальное время ответа — это сколько?
Чем меньше, тем лучше.
- До 300 миллисекунд — очень хороший результат, можно спать спокойно.
- От 300 до 700 миллисекунд — тоже неплохо, волноваться повода нет.
- Если время ответа вашего сайта приближается к секунде, или ещё выше — повод принимать меры.
Если вы этого ещё не сделали, то рекомендую прямо сейчас проверить скорость ответа вашего сайта. Результат может быть неожиданным для вас. Более того, рекомендую делать это регулярно. Для этого в нашем тестере предусмотрена возможность сохранять проверки. Достаточно один раз сохранить все страницы, которые вы желаете проверять, и далее проверять их мгновенно за 1 клик.
Помните, что скорость ответа влияет не только на восприятие сайта людьми (согласитесь, неприятно, когда при серфинге по сайту наблюдаются задержки при открытии страниц), но и на восприятие сайта поисковыми системами. Давно не секрет, что данный фактор оказывает влияние на ранжирование.
Коды ответов HTTP
Код состояния HTTP — это число, состоящее из трех цифр. Первая цифра означает группу, к которой принадлежит код.
Существуют следующие группы:
- 1xx — Информационные коды
- 2xx — Успешные коды
- 3xx — Коды перенаправлений
- 4xx — Коды ошибок клиента
- 5xx — Коды ошибок сервера
Проверка 304 Not Modified
Правильно настроенный сервер должен обрабатывать заголовок If-Modified-Since. Этот заголовок содержит дату и спрашивает, была ли изменена страница после этой даты. Если страница не была изменена, сервер должен вернуть ответ 304 Not Modified. При этом ответ содержит только заголовки и не содержит тело страницы. Это значительно экономит время и трафик при обходе вашего сайта поисковыми роботами.
Помимо этого, для корректной работы этой схемы сайт должен на каждый GET запрос возвращать заголовок Last-Modified, содержащий дату последнего изменения страницы. Браузеры и поисковые роботы сохраняют эту дату и при следующем запросе используют именно её для заголовка If-Modified-Since как бы спрашивая, изменилась ли страница с тех пор, нужно ли её скачивать заново.
calcus.ru
Что такое код статуса HTTP?
Код статуса HTTP (или код ответа сервера) — трёхзначное число, которое обозначает определенный статус запрашиваемой страницы.
Пример:
HTTP/1.1 200 OK , где
HTTP/1.1 — версии протокола,
200 — код успешного выполнения запроса.
Подробнее посмотреть значения кодов ответа сервера можно в этой статье.
В этой статье мы рассмотрим различные задачи, связанные с проверкой ответа сервера, а также поговорим о полезных инструментах, которые помогут нам решить их.
Проверить код ответа сервера страницы
Для того чтобы узнать код ответа сервера страницы, воспользуемся популярным онлайн сервисом. Mainspy позволяет определить ответ сервера по заданному урлу, что может быть полезно для определения наличия страницы или работоспособности сайта в целом.
Все довольно просто: необходимо вставить URL страницы и нажать кнопку “Проверить”.
Также можно воспользоваться проверкой ответа сервера в Яндекс Вебмастере , инструмент доступен только для подтверждённых сайтов.
Узнать код ответа сервера всех страниц сайта
Для пакетной проверки ответа сервера вышеизложенный сервис нам, к сожалению, не подойдет, поэтому воспользуемся десктопными приложениями Xenu или Spider, которые помогут пропарсить все страницы сайта и проверить код ответа всех страниц.
Получение статуса страниц в Xenu
В главном меню перейдем «File- Check URL». Введем адрес сайта и запустим проверку урлов на ответ сервера
Результат проверки статуса ответа сервера можно будет увидеть в колонке «Status».
Получение статуса страниц в Spider
Запускаем приложение, вводим URL. Результат смотрим в колонке “Статус”.
Массовая проверка страниц на код ответа сервера
Используется для проверки группы Url-ом нескольких сайтов или вполне конкретных страниц. В решении этой задаче нам поможет этот сервис. Вводим списком адреса.
Получаем результат.
Есть небольшое ограничение: максимальное количество Url-ов составляет 100 адресов.
Но это совсем не проблема. Я предлагаю вам решение, которое вы можете реализовать на вашем веб-сервере (необходимы небольшие знания PHP).
Рассмотрим функцию get_headers, которая возвращает все заголовки, посланные сервером в ответ на HTTP запрос.
Пример: Возвращает код ответа сервера заданного URL-а.
<!--?php ini_set('max_execution_time', 900); $url='//semantica.in/'; $code=get_headers($url); echo($code[0]); ?>
Немного доработав php код , мы сможем списком вводить URL-ы и получать коды ответа сервера:
<form action="index.php" method="POST"> <textarea name='url'></textarea> <button type="submit">Send</button> </form> <?php if(!empty($_POST["url"])){ $url = $_POST['url']; $links = explode("rn",$url); $count = count($links); for ($i =0; $count > $i; $i++) { $url = $links[$i]; $head = get_headers($url); $code = $head[0]; echo "$url $code"; echo "<br>"; } } ?>
Мы рассмотрели популярные задачи, которые могут возникнуть перед вебмастером. Надеюсь, что информация окажется для вас полезной.
semantica.in
Проверка кода ответа сервера
Вы можете проверить http-заголовки любой страницы сайта, и узнать какой код ответа выдает сервер. Это поможет вам узнать правильность настройки сервера, проверить редиректы и узнать скорость загрузки страницы.
| Code | Код ответа сервера |
|---|---|
| 100 Continue | Сервер удовлетворён начальными сведениями о запросе. Можно продолжать пересылать заголовки. |
| 101 Switching Protocols | Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. |
| 102 Processing | Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. |
| 200 OK | Успешный запрос ресурса. |
| 201 Created | В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. |
| 202 Accepted | Запрос был принят на обработку, но обработка не завершена. |
| 203 Non-authoritative Information | Успешный запрос ресурса, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. |
| 204 No Content | Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. |
| 205 Reset Content | Сервер обязывает сбросить введённые пользователем данные. |
| 206 Partial Content | Сервер удачно выполнил частичный GET возвратив только часть. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. |
| 207 Multi-Status | Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. |
| 208 Already Reported | Члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова. |
| 226 IM Used | Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. |
| 300 Multiple Choices | По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. |
| 301 Moved Permanently | Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. |
| 302 Found | Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. |
| 303 See Other | Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. |
| 304 Not Modified | Клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. |
| 305 Use Proxy | Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. |
| 307 Temporary Redirect | Запрашиваемый ресурс короткое время доступен по другому URI (указывается в поле Location заголовка). |
| 308 Permanent Redirect | Запрашиваемый ресурс теперь постоянно находится в другом URI (указывается в поле Location заголовка). Данный код ответа имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если POST использовался в первом запросе, POST должен использоваться и во втором запросе. |
| 400 Bad Request | Запрос не понят сервером из-за наличия синтаксической ошибки. |
| 401 Unauthorized | Запрос требует идентификации пользователя. |
| 402 Payment Required | В настоящий момент этот код не используется |
| 403 Forbidden | Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе со стороны клиента к указанному ресурсу. |
| 404 Not Found | Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. |
| 405 Method Not Allowed | Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов. |
| 406 Not Acceptable | Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. |
| 407 Proxy Authentication Required | Запрос требует идентификации прокси-сервера. |
| 408 Request Timeout | Время ожидания сервером передачи от клиента истекло. |
| 409 Conflict | Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. |
| 410 Gone | Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен |
| 411 Length Required | Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. |
| 412 Precondition Failed | Ни одно из условных полей заголовка запроса не было выполнено. |
| 413 Payload Too Large | Сервер по каким-то причинам не может передать запрашиваемый объём информации. |
| 414 Request-URI Too Long | Сервер не может обработать запрос из-за слишком длинного указанного URI. |
| 415 Unsupported Media Type | По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. |
| 416 Requested Range Not Satisfiable | В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. |
| 417 Expectation Failed | По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. |
| 418 I’m a teapot | Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324. |
| 421 Misdirected Request | Запрос был перенаправлен на сервер, не способный дать ответ. |
| 422 Unprocessable Entity | Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом. |
| 423 Locked | Целевой ресурс из запроса заблокирован от применения к нему указанного метода. |
| 424 Failed Dependency | Реализация текущего запроса может зависеть от успешности выполнения другой операции. |
| 426 Upgrade Required | Сервер указывает на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. |
| 428 Precondition Required | Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. |
| 429 Too Many Requests | Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. |
| 431 Request Header Fields Too Large | Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. |
| 444 Connection Closed Without Response | Сервер не вернул информацию пользователю и закрыл соединение. |
| 449 Retry With | Возвращается сервером если для обработки запроса от клиента поступило не достаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. |
| 451 Unavailable For Legal Reasons | Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. |
| 499 Client Closed Request | Клиент закрыл соединение, прежде чем сервер ответит на запрос. |
| 500 Internal Server Error | Внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx. |
| 501 Not Implemented | Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. |
| 502 Bad Gateway | Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции. |
| 503 Service Unavailable | Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. |
| 504 Gateway Timeout | Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса. |
| 505 HTTP Version Not Supported | Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. |
| 506 Variant Also Negotiates | В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается. |
| 507 Insufficient Storage | Не хватает места для выполнения текущего запроса. Проблема может быть временной. |
| 508 Loop Detected | Обнаружено бесконечное перенаправление |
| 509 Bandwidth Limit Exceeded | Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. |
| 510 Not Extended | На сервере отсутствует расширение, которое планирует использовать клиент. |
| 511 Network Authentication Required | Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. |
| 520 Unknown Error | Возникает когда сервер CDN не смог обработать ошибку веб-сервера. |
| 521 Web Server Is Down | Возникает когда подключения CDN отклоняются веб-сервером. |
| 522 Connection Timed Out | Возникает когда CDN не удалось подключиться к веб-серверу. |
| 523 Origin Is Unreachable | Возникает когда веб-сервер недостижим. |
| 524 A Timeout Occurred | Возникает при истечении таймаута подключения между сервером CDN и веб-сервером. |
| 525 SSL Handshake Failed | Возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером. |
| 526 Invalid SSL Certificate | Возникает когда не удаётся подтвердить сертификат шифрования веб-сервера. |
| 599 Network Connect Timeout Error | Ошибка таймаута — сетевые подключения. |
