1 / 3
Урок 5 Часть 3 Заголовки HTTP
Лекция 2: HTTP, важные заголовки, коды ответа
Модуль 1. Работа с протоколом HTTP – cookie, заголовки ответа сервера
так я уже расказывал, что когда идут какие-то запросы на сервер там есть заголовки ответа, заголовки запроса здесь я на слайде примерно как бы здесь все это расшифровал подробно рассказывать не буду, единнственное что про группы четыре основные я не упомянул ечть основны general headers они должны включаться в любое сообщение клиента и сервера например вот у нас есть заголовок запроса accept это главный заголовок, он всегда должен присутствовать accept lenguage, accept encoding они всегда есть как вы уже заметили, на всех сайтах post тоже на всех в сайтах присутствует, во всех запросах заголовки запроса мы уже расссмотрели используется только в запросах клиента request header, т.е. заголовки запроса вот это части, она всегда формируется на клиенте браузере и посылается на сервер response headers - это заголовки ответа, только для ответа сервера это уже эта часть непосредственно - вот они заголовки ответа и утешен headers - заголовки сущности, они сопровождают каждую сущность сообщения здесь их не видно, они там как бы внутри скрыты типа вот этого и всякие другие и прмер http диалога я вам показал здесь я на слайде привожу пример get запроса, который происходит это мы уже подробно рассмотрели, но и здесь на слайде тоже есть пример т.е. когда клиент запрашивает какую то страницу, здесь формируется вот такой заголовок вот такие заголовки запросов какой host, какой user, что он хочет и ответ который пришел с сервера, что документ у нас есть и прочие остальные заголовки осталось рассмотреть у нас сам url, параметры запроса и перейти непосредственно get и post типы чтобы уже принимать php и как то обрабатывать напомню что url - это uniform resource locator как бы запрашивает документ ищет место где он находится и часто он состоит из таких вот частей т.е. сначала это протокол кстати протоколы могут быть разными многие из вас слышали такой протокол как FTP - file transfer protokol протокол для передачи файлов посмотрим http он состоит из хоста сервера сайта, где расположен этот документ путь до этого документа он может быть выглядит в таком виде даже с русскими символами может выглядеть в любом другом просто как как будто мы переходим по папкам и т.д. очень часто передаются какие-то параметры после знака вопроса здесь очень важно сейчас узнать для себя и запомниnm следующую вещь что все параметры всегда передаются после знака вопроса сейчас закрою все лишнее и мы уже посмотрим на нашем сайте как это выглядит вот наш старый документ сейчас все это подчищу и мы посмотрим что у нас происходит с параметрами напомню что все параметры, которые идут после вопроса вся часть попадает в массив get этот массив одноименный по тем типам, которые мы рассматривали т.е. есть массив get, есть массив post и с ними мы будем работать посмотрим что у нас здесь в данном случае массив этот пустой потому что никакого параметра небыло передано затем я пишу знак вопроса, и указываю что там, допустим, меню и мы видим что меню -ушло как ключ ассоциативного массива если мы поставим знак равно, и присвоим в меню, что-то типа 1 2 3 мы получим следующую конструкцию менб становится как ключ ассоциативного массива а 1 2 3 идет в значение сюда сможем написать какой-то текст у меня хром не правиль подставляет, давайте если мне нужно указать несколько параметров, я ставлю значек амперсанда и указываю меню2 равно 2 3 4 меню 4 равно привет и т.д я могу это делать до бесконечности выглядит это таким образом сами параметры попадают в ключи ассоциативных массивов то что стоит после равно попадает в их значение это очень удобно чтобы смотреть какие параметры пришли методом get и спомощью php их можно в таком ключе обрабатывать если мы в конце укажем амперсанд то php уже не увидет дальше парметра и не будет ничего обрабатывать как я уже говорил, можно просто указывать вопрос, можно указывать само сам документ, унас был index.php можно и не указывать дело в том что у нас есть по умолчанию основной как бы default документ, который показывается всегда в любом случае это у нас - index.php это определено у нас в конфигурационных файлах можно покопаться и посмотреть где где эта строка, где-тот параметр описан в конфигурационных файлах апача или в самом php поэтому, в таком случае можно не указывать этот индексный документ, а просто сразу писать впрос меню и т.д. и т.п. для этого что бы вам получше уяснить как обрабатывать параметры, я подготовил специальное домашнее задание, чтобы я здесь привел пример, но сейчас все это рассмотри мы должны научится принимать парметры, которые идут из get с помощью get, для этого у меня есть специальное домашнее задание оно находится в файле DZ5.1 сейчас я его открою что здесь такое здесь есть новости я их забил просто как строки чтобы было удобно их вводить в какой-то другой последовательности либо писать свои собственные новости здесь есть специальная функция, которая называется explode, что она делает она просто эти строки разбивает в массив и каждую строку записывает как элемент в качестве разбивки, и в качестве элемента разбивки, она использует перенос строки просто как это выглядит я её скопирую сюда т.е. это функция ищет вот этот элемент перенос строки, в данно случае найдет вот здесь, и здесь, издесь и просто раздробит эту строку на составляющие части и каждую часть поместит в качестве элемента массива выглядит это примерно так то есть здесь строка у нас четыре новосибирские компании вошли в сотню лучших работодателей она поместила это как нудлевой элемент и дальше по списку ваша задача какая вы вводите идентификатор, т.е. параметр идентификатора и говорите равно 8 скажем и жмете Enter, здесь это должно приняться каким то образом и мы должны на экране получить новость которая идет под этим номером скажем я ввожу 8-ую а восьмая - это звезды телешоу мы так и получаем если я ввожу сюда седьмую у вас должна вывестить седьмая но однако здесь чтобы вам небыло так легко я сделал некоторые хитрости, т.е. у вас должна быть объязательно функция вывода всего списка новостей у вас должна быть функция вывода конкретной новости в точке входа вы обрабатываете идентификатор и если эта новость присутствует вывести её на сайте если новости нет мы выводим весь список снова вот в таком виде должно все работать более того вы должны проверять был ли передан идентификатор новости в качестве параметра, т.е. я мог бы вывести скажем, меню равно 7 и вот у меня уже идкт какие-то ошибки underfined index и все такое прочее то есть вы должны это все дело отлавливать и если то есть вы должны это все дело отлавливать и если параметр не был передан выводить 404 ошибку 404 ошибка выводится, с помощью специального специальной функции, которая называется header и она здесь есть таким образом она выглядит я здесь оставлю ссылку на документацию чтобы все это дело прочитали и сделали самостоятельно это то что у нас касается метода get
Предусматривается размещение значения на нескольких строках (перенос строки). Для указания переноса в начале следующей строки должен находиться хотя бы один пробельный символ.
Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один, только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовков должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.
Пример с многострочными значениями и одинаковыми именами заголовков (обратите внимание на регистр символов и пробелы):
Content-type: text/html; charset=windows-1251 Allow: GET, HEAD Content-Length: 356 ALLOW: GET, OPTIONS Content-Length: 1984
Правильный компактный вариант преобразования и интерпретации:
Content-Type: text/html;charset=windows-1251 Allow: GET,HEAD,OPTIONS Content-Length: 1984
В этом случае недопустимо принимать значение Content-Length, равное 356. При объединении значений Allow, чтобы не потерять семантический смысл, была добавлена запятая в конец первого поля и убран бессмысленно дублирующийся элемент «GET».
Только дата указывается в заголовках Date , Expires , Last-Modified , If-Modified-Since , If-Unmodified-Since . Дата может присутствовать в заголовках If-Range и Warning .
В HTTP исторически используется три формата:
Сейчас рекомендуется использовать только первый формат по RFC 822 , но для совместимости клиентам и серверам лучше поддерживать и другие.
Время всегда указывается для часового пояса GMT (UTC+0). Год записывается четырьмя цифрами. День, час, минута и секунда дополняются нулями до двух символов. Для названий месяца и дня недели применяются трёхбуквенные стандартные сокращения на английском языке.
Дни недели начиная с понедельника: Mon , Tue , Wed , Thu , Fri , Sat , Sun .
Месяцы с января по декабрь: Jan , Feb , Mar , Apr , May , Jun , Jul , Aug , Sep , Oct , Nov , Dec .
В PHP для преобразования местного времени во время по Гринвичу используется функция gmdate(). Примеры формирования дат для заголовков HTTP:
// Текущая дата формирования документа: header ("Date: " . gmdate (DateTime :: RFC850 )); // Дата модификации указанного файла: $fp = "data/my-foo.txt" ; // путь к файлу header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" , filemtime ($fp )) . " GMT" ); // Документ предположительно изменится через час: header ("Expires: " . gmdate ("D, d M Y H:i:s" , time () + 3600 ) . " GMT" ); // 3600 - количество секунд относительно текущего момента.
При работе с фрагментами содержимого в специальных заголовках используются байтовые диапазоны (англ. byte ranges ). В них можно указать как один фрагмент, так и несколько разделяя их запятыми « , ». Диапазоны применяются в заголовках Range и Content-Range . В заголовке Accept-Ranges перечисляются только единицы измерения.
В байтовых диапазонах обязательно в начале указываются название единиц измерения за которым следует символ « = ». В настоящий момент кроме единиц bytes никакие другие не применяются. За символом « = » располагаются сами диапазоны. Каждый из них является разделённой дефисом « - » парой натуральных чисел или нуля и натурального числа. Первый элемент указывает начальный байт, а второй - конечный. Нумерация в диапазонах начинается с нуля.
Начальный или конечный байт может быть не указан. При отсутствии последнего байта считается что речь идёт о фрагменте от начального байта до конца содержимого. Если отсутствует начало, то номер конечного байта воспринимается как количество запрашиваемых байт от конца содержимого.
Если первый байт больше чем последний, то диапазон считается синтаксически недействительным (англ. syntactically invalid ). Поля заголовка, содержащие диапазоны с синтаксически недействительными значениями, игнорируются. Если первый байт выходит за пределы объёма ресурса, то диапазон игнорируется. Если последний байт выходит за пределы содержимого, то диапазон обрезается до конца.
Блок байтовых диапазонов считается выполнимым если в нём содержится хотя бы один доступный диапазон. Если же все диапазоны некорректны или выходят за пределы объёма ресурса, то серверу следует вернуть сообщение со статусом 416 (Requested range not satisfiable).
Примеры (весь объём ресурса - 5000 байт):
Язык разметки HTML позволяет задавать необходимые значения заголовков HTTP внутри
с помощью тега . При этом название заголовка указывается в атрибуте http-equiv , а значение - в content . Почти всегда выставляется значение заголовка Content-Type с указанием кодировки, чтобы избежать проблем с отображением текста браузером. Также не лишним является указание значения заголовка Content-Language:< html > < head > < meta http-equiv = "Content-Type" content = "text/html;charset=windows-1251" > < meta http-equiv = "Content-Language" content = "ru" > ...
HTTP (HyperText Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP , XML-RPC , WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP - протокол прикладного уровня, аналогичными ему являются FTP и SMTP - простой протокол передачи почты . Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI . В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Расширяемость
Возможности протокола легко расширяются благодаря внедрению своих собственных заголовков, сохраняя совместимость с другими клиентами и серверами. Они будут игнорировать неизвестные им заголовки, но при этом можно получить необходимую функциональность при решении специфической задач.
HTTP/1.1 - текущая версия протокола. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.
HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI- программы должны пользоваться скрытыми полями ввода или внешними средствами, например Cookie .
Метод HTTP - последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
Все заголовки в протоколе HTTP разделяются на четыре основных группы (в нижеприведенном порядке рекомендуется посылать заголовки получателю):
General Headers (Основные заголовки) - должны включаться в любое сообщение клиента и сервера.
Request Headers (Заголовки запроса) - используются только в запросах клиента.
Response Headers (Заголовки ответа) - только для ответов от сервера.
Entity Headers (Заголовки сущности) - сопровождают каждую сущность сообщения. В отдельный класс заголовки сущности выделены для того, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (MIME).
Все необходимые для функционирования HTTP заголовки описаны в основных RFC . При необходимости можно создавать свои заголовки. Традиционно к именам таких дополнительных заголовков добавляют префикс "X-" для избежания конфликта имён с возможно существующими.
Строки после главной строки запроса (GET /index.html HTTP/1.1) имеют следующий формат: Параметр: значение. Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Connection: Keep-Alive).
Параметр Connection (соединение) - может принимать значения Keep-Alive и close. В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершённой, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы - изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.
Параметр User-Agent - значением является "кодовое обозначение" браузера.
Параметр Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером.
Параметр Host - имя домена, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP- адресом. В этом случае имя виртуального домена определяется по этому полю.
Параметр Last-Modified (модифицирован в последний раз) (W3C Last-Modified) - дата и время последнего изменения документа. Используя его, клиент, подобно случаю с ETag, может обращаться к серверу с запросом "If-Modified-Since" - в этом случае сервер должен сравнить дату последней модификации копии, сохраненной на клиенте, с актуальной датой последней модификации. Если они совпадут, это значит, что копия в кэше клиента не устарела, и повторное скачивание не нужно (код ответа "304 Not Modified"). Last-Modified также необходим для корректной обработки сайта роботами, которые используют информацию о дате модификации страниц в целях сортировки результатов поиска по дате, а также для определения частоты обновляемости Вашего сайта.
Для SSI документов Apache будет выдавать "Last-Modified" в том случае, если указана директива "XBitHack full" (например, в файле.htaccess)
Параметр ETag (объектная метка) - появился в HTTP 1.1(W3C ETag). ETag служит для присвоения каждой странице уникального идентификатора, значение которого меняется при изменении страницы (документа). ETag представляет собой хеш («отпечаток») байтов документа, если в документе изменится хоть один байт, то изменится и ETag. ETag используется при кэшировании документа. Этот заголовок сохраняется на клиенте, и в случае повторного обращения к документу позволяет браузеру обратиться к серверу с запросом ‘If-None-Match’, а сервер должен по значению ETag- метки определить, не изменился ли документ(страница), и если нет, ответить кодом ‘304 Not Modified’.
Параметр Expires (истечение)(W3C Expires) - он сообщает браузеру, какой временной промежуток можно считать, что копия страницы в кэше свежа, и вообще не обращаться к серверу с запросами. Это удобно для таких файлов, о которых вы точно знаете, что они не изменятся ближайший час/день/месяц: фоновая картинка страницы, например.
Другие заголовки HTTP:
HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
HTTP_X_COMING_FROM
HTTP_COMING_FROM
HTTP_X_CLUSTER_CLIENT_IP
HTTP_XROXY_CONNECTION
HTTP_PROXY_CONNECTION
HTTP_USERAGENT_VIA - прокси
HTTP запрос состоит из трех частей: строки запроса (ответа), раздела заголовка, за которым следует необязательное тело. Заголовки представляют собой простой текст, при этом каждый заголовок отделен от следующего символом новой строки(\r\n), в то время как тело может быть как текстом, так и бинарными данными. Тело отделяется от заголовков двумя символами новой строки.
Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.
Клиент инициирует транзакцию следующим образом:
Клиент устанавливает связь с сервером по назначенному номеру порта, официальный номер порта по умолчанию - 80. Затем клиент посылает запрос документа, указав метод, адрес документа и номер версии HTTP. Например, в главной строке запроса GET /index.html HTTP/1.1
используется метод GET , которым с помощью версии 1.1 HTTP запрашивается документ index.html.
Клиент посылает информацию заголовка (необязательную, заголовок host обязателен), чтобы сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать. Вся информация заголовка указывается построчно, при этом в каждой строке приводится имя и значение. Например, приведённый ниже заголовок, посланный клиентом, содержит его имя и номер версии, а также информацию о некоторых предпочтительных для клиента типах документов: Host: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Завершается заголовок пустой строкой.
Послав запрос и заголовки, клиент может отправить и дополнительные данные, например, для CGI скриптов.
Сервер отвечает на запрос клиента следующим образом:
Первая часть ответа сервера - строка состояния, содержащая три поля: версию HTTP, код состояния и описание. Поле версии содержит номер версии HTTP, которой данный сервер пользуется для передачи ответа. Код состояния - это трехразрядное число, обозначающее результат обработки сервером запроса клиента. Описание, следующее за кодом состояния, представляет собой просто понятный для человека текст, поясняющий код состояния. Например, строка состояния HTTP/1.1 304 Not Modified
говорит о том, что сервер для ответа использует версию HTTP 1.1. Код состояния 304 означает, что клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента.
После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка: Date: Thu, 15 Dec 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8
Завершает заголовок пустая строка.
Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI- программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.
Код состояния HTTP (HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.
Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния:
1xx : Informational (Информационные). Информационные коды состояния, сообщающие клиенту, что сервер пребывает в процессе обработки запроса. Реакция клиента на данные коды не требуется;
2xx : Success (Успешно).
200 OK (Хорошо). Появился в HTTP/1.0. Успешный запрос ресурса. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.
3xx : Redirection (Перенаправление(переадресация)). Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. Многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды 303 и 307 вместо 302. Изменять метод запроса нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.
302 Found (Найдено). Введено в HTTP/1.0. Запрошенный документ временно доступен по другому URI , указанному в заголовке в поле Location.
4xx : Client Error (Ошибка клиента). Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD , сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
404 Not Found (Не найдено). Появился в HTTP/1.0. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI .
5xx : Server Error (Ошибка сервера)
HTTP/2 (изначально HTTP/2.0) - вторая крупная версия сетевого протокола HTTP. Протокол основан на SPDY (HTTP-совместимый протокол, разработанный Google).
Протокол HTTP/2 является бинарным. По сравнению с предыдущим стандартом изменены способы разбития данных на фрагменты и транспортирования их между сервером и клиентом.
В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений.
С помощью заголовков http происходит обмен служебными сведениями между клиентом и сервером. Эта информация остается невидимой для пользователей, но без нее невозможна правильная работа браузера. Для обычных пользователей сведения об этом и о задачах http заголовков покажутся довольно сложными, но на самом деле они не содержат трудных формулировок. Это то, с чем сталкивается веб-пользователь ежедневно.
«Протокол передачи гипертекста» - именно так переводится Благодаря его существованию, возможна связь «клиент-сервер». Если объяснить простыми словами, пользователь браузера посылает запрос, инициируя соединение с сервером. Последний, по умолчанию, ждет запрос от клиента, обрабатывает его и посылает обратно итоговую информацию или ответ. В поисковой строке пользователь «вбивает» адрес сайта, который начинается с http:// и получает результат в виде открывшейся страницы.
Когда печатается адрес сайта в соответствующей строке, браузер находит требующийся сервер с помощью DNS. Сервер распознает http заголовок (один или несколько), который посылает ему клиент, а затем выдает требуемый header. Набор обязательных состоит из уже существующих заголовков и не найденных.
В общем, http заголовки достаточно эффективные. Их не видно в HTML-кодировании, они отправляются перед запрашиваемыми сведениями. Многие заголовки автоматически высылаются сервером. Для того чтобы его отослать на языке PHP, следует воспользоваться функцией header.
Схема взаимодействия браузера и сайта достаточно простая. Так, http заголовок начинает строку запроса, который далее посылается серверу. В ответ приходит нужная клиенту информация. Между прочим, http протокол уже семнадцать лет - самый используемый в Интернете. Он простой, надежный, работает быстро и гибко. Главная задача http - запрос сведений с web-сервера. Клиентом является браузер, а сервером - ligthttp, apache, nginx. Если соединение между ними произошло успешно, сервер в ответ на запрос получает нужные сведения. Информация http содержит текстовые, звуковые файлы, видео.
Протокол может быть транспортом для других. Запрос клиента состоит из трех частей:
Стартовая строка - обязательный элемент запроса поля заголовков http. Структура запроса пользователя состоит из трех основных частей:
Современные браузеры используют версию 1.1. Далее следуют заголовки в формате "Имя: значение".
Суть в том, что кэширование обеспечивает хранение HTML-страниц, других файлов в кэше (место в операционной памяти, на жестком диске компьютера). Это нужно для того чтобы ускорить к ним повторный доступ и сэкономить трафик.
Кэш имеет браузер клиента, промежуточный шлюз и прокси-сервер. Перед тем как отправить сообщение по URL, браузер проверит наличие объекта в кэше. Если объекта нет, запрос передается следующему серверу, где проверяется кэширование http заголовков на сервере nginx. Шлюзы и прокси используются разными пользователями, поэтому кэш является разделяемым.
HTTP-кэширование способно не только существенно ускорить работу сайта, но и предоставить старую версию страницы. С помощью происходит отправка заголовков на отклик. При этом не может быть кэширована информация, запрошенная по протоколу HTTPS.
Одними из самых главных механизмов кеша считаются http заголовки expires. Эти заголовки сообщают о сроке годности предоставленной в отклике информации. В них указывается время и дата, когда кэш будет считаться устаревшим. Например, такой заголовок выглядит следующим образом: Expires: Wen, 30 Nov 2016 13:45:00 GMT. Данная структура используется почти везде, в том числе для кэширования страниц и картинок. Если пользователь выберет старую дату, сведения не будут кэшироваться.
Заголовки http proxy относятся к категории header link. Они не кэшируются по умолчанию. Чтобы кэш работал правильно, каждый URL должен соответствовать одному варианту содержимого. Если страница действует на двух языках, каждая версия должна иметь собственный URL. Заголовок vary сообщает кэшу названия заголовков запроса. К примеру, если отображение запроса зависит от браузера, серверу необходимо также отправлять заголовок. Таким образом, в кэше сохраняются разные варианты запросов и типы документов. TTP заголовок accept необходим для того чтобы составлять списки допустимых форматов используемого ресурса, с ним достаточно легко работать, так как он отсеивает ненужные.
Всего существует четыре группы заголовков, которые передают служебную информацию. Это основные заголовки - они содержатся в любом сообщении сервера и клиента, запроса и ответа, а также сущности. Последние описывают содержание любого сообщения от клиента и сервера.
HTTP заголовок authorization считается дополнительным. Когда web-страница спрашивает у клиента авторизацию, браузер отображает специальное окно с полями для ввода логина и пароля. После того как пользователь введет свои данные, браузер передает запрос http. Он содержит заголовок «авторизация».
Чтобы увидеть http заголовок, необходимо установить плагины для браузера, например, firefox:
Когда плагины будут установлены, запустите их и браузера.
Методы, которые используются в HTTP, имеют сходства с инструкциями, которые передаются в виде сообщения серверу. Это специальное слово на английском языке.
Сервер отвечает на запросы клиента длинными сообщениями. Ответ состоит из нескольких строк, в которых указывается версия протокола, код статуса сервера (200). Он говорит о том, что изменилось на сервере за время обработки поступившего запроса:
URL - это сердце веб-общения между клиентом и сервером. Запрос обычно отправляется через URL - единый указатель ресурсов. Структура запроса url очень проста. Она состоит из нескольких элементов: протокол http (заголовок), hoot (адрес сайта), port, resourte path и query.
Протокол доступен также для безопасного соединения https и обмена информацией. URL-адрес содержит информацию о размещении конкретного сайта в Интернете. Адрес включает в себя имя домена, путь к странице, а также ее название.
Основной недостаток работы с URL - это неудобное взаимодействие с латинским алфавитом, а также цифрами и символами. В SEO оптимизации играет не последнюю роль.
Активным пользователям компьютеров и разработчикам не помещает ознакомиться с некоторыми профессиональными рекомендациями, которые дают специалисты в этой области:
Код состояния HTTP (англ. HTTP status code ) - код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Пример:
403 Access allowed only for registered users
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния:
Ниже, представлены коды ответа из реестра кодов состояния IANA.
1xx: Informational
В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
100 Continue
(русск. Продолжать
)
Сервер удовлетворён начальными сведениями о запросе. Клиент может продолжать пересылать заголовки.
101 Switching Protocols
(русск. Переключение протоколов
)
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.
102 Processing
(русск. Идёт обработка
)
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.
2xx: Success
Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
200 OK
(русск. Хорошо
)
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.
201 Created
(русск. Создано
)
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.
202 Accepted
(русск. Принято
)
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.
203 Non-Authoritative Information
(русск. Неавторитетная информация
)
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.
204 No Content
(русск. Нет содержимого
)
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.
205 Reset Content
(русск. Сбросить содержимое
)
Сервер обязывает клиента спросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.
206 Partial Content
(русск. Частичное содержимое
)
Сервер удачно выполнил запрос клиента, но передал только часть документа. Такой ответ сервер может отправить если в заголовке запроса клиента есть поле Content-Range. Особое внимание при работе с подобными ответами следует уделить кэшированию.
207 Multi-Status
(русск. Многостатусный
)
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.
226 IM Used
(русск. IM использовано
)
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.
3xx: Redirection
Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).
Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.
300 Multiple Choices
(русск. Несколько выборов
)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.
301 Moved Permanently
(русск. Перемещёно окончательно
)
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.
302 Found
(русск. Найдено
)
Запрошенный документ был временно перенесен на другой URI, указанный в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.
303 See Other
(русск. Смотреть другое
)
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.
304 Not Modified
(русск. Не изменено
)
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.
305 Use Proxy
(русск. Использовать прокси
)
Запрос к запрашиваемому ресурсе должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).
306 (Reserved)
(русск. Зарезервировано
)
Использовалось раньше. В настоящий момент зарезервировано.
307 Temporary Redirect
(русск. Временное перенаправление
)
Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.
4xx: Client Error
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
400 Bad Request
(русск. Плохой запрос
)
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.
401 Unauthorized
(русск. Неавторизован
)
Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.
402 Payment Required
(русск. Необходима оплата (зарезервировано)
)
Предполагается использовать в будущем. В настоящий момент не используется.
403 Forbidden
(русск. Запрещено
)
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.
404 Not Found
(русск. Не найдено
)
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.
405 Method Not Allowed
(русск. Метод не поддерживается
)
Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.
406 Not Acceptable
(русск. Не приемлемо
)
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.
407 Proxy Authentication Required
(русск. Необходима авторизация прокси
)
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.
408 Request Timeout
(русск. Время ожидания истекло
)
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.
409 Conflict
(русск. Конфликт
)
Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.
410 Gone
(русск. Удалён
)
Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.
411 Length Required
(русск. Необходима длина
)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.
412 Precondition Failed
(русск. Условие «ложно»
)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.
413 Request Entity Too Large
(русск. Запрашиваемые данные слишком большие
)
Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.
414 Request-URI Too Long
(русск. Запрашиваемый URI слишком длинный
)
Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.
415 Unsupported Media Type
(русск. Неподдерживаемый тип данных
)
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.
416 Requested Range Not Satisfiable
(русск. Запрашиваемый диапазон не достижим
)
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.
417 Expectation Failed
(русск. Ожидаемое ошибочно
)
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.
422 Unprocessable Entity
(русск. Необрабатываемый экзмепляр
)
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.
423 Locked
(русск. Заблокировано
)
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.
424 Failed Dependency
(русск. Невыполненная зависимость
)
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.
426 Upgrade Required
(русск. Необходимо обновление
)
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.
5xx: Server Error
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
500 Internal Server Error
(русск. Внутренняя ошибка сервера
)
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.
501 Not Implemented
(русск. Не выполнимо
)
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.
502 Bad Gateway
(русск. Плохой шлюз
)
Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.
503 Service Unavailable
(русск. Сервис недоступен
)
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.
504 Gateway Timeout
(русск. Шлюз не отвечает
)
Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.
505 HTTP Version Not Supported
(русск. Версия HTTP не поддерживается
)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.
506 Variant Also Negotiates (Experimental)
(русск. Вариант тоже согласован (экспериметальное)
)
В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.
507 Insufficient Storage
(русск. Закончилось место
)
Не хватает места для выполнения текущего запроса. Проблема может быть временной.
510 Not Extended
(русск. Не расширено
)
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.
Когда мы открываем любую веб-страницу нужного нам сайта вместе с HTML кодом страницы сервер передает код статуса запроса и http заголовки. По коду статуса программы могут быстро определить все ли прошло успешно или, например, такой страницы нет на сервере. Заголовки содержат информацию для браузера, которая указывает как нужно обрабатывать страницу и что с ней делать.
Обычным пользователям эта информация ни к чему, но если вы администратор сайта или технический специалист, она может быть для вас очень полезной. В этой статье мы рассмотрим как выполняется проверка кода ответа сервера и http заголовков с помощью утилиты curl.
Для нормальной работы различных программ, работающих по протоколу HTTP сервер возвращает не только текст страницы, но и трехзначный код, который позволяет определить результат запроса. С помощью этого кода можно не только описать какая ошибка возникла во время обработки, но и перенаправить пользователя на другую страницу, или же сказать, что страница не была изменена. Вот самые распространенные коды ответа сервера:
1xx - информационные:
2хх - операция успешна:
3xx - перенаправления:
4хх - ошибка в запросе:
5хх - ошибка сервера:
С помощью http заголовков клиент и сервер обмениваются информацией и командами между собой. Они используются для согласования метода, протокола, кодировки, языка и многих других параметров работы. Рассмотрим основные заголовки, которые будет отправлять сервер:
Все это было вступлением, чтобы вы смогли понять что мы дальше собираемся делать, поскольку мы рассмотрим не только то как посмотреть заголовки и ответ сервера, но и то какими они должны быть для вашего сайта.
Чтобы увидеть только код ответа страницы достаточно выполнить такую команду:
curl -s -o /dev/null -w "%{http_code}" https://сайт
Или, если хотите, чтобы ответ выглядел более естественно:
curl -I https://сайт 2>
Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:
curl -I http://сайт 2>/dev/null | head -n 1 | cut -d$" " -f2
curl -I https://www.сайт 2>/dev/null | head -n 1 | cut -d$" " -f2
Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.
Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:
curl -I https://сайт
Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:
Таким способом может быть выполнена проверка http заголовков для любой страницы или ресурса чтобы сразу определить все ли отправляется правильно. Например, посмотрим заголовки для изображения:
curl -I https://сайт/wp-content/uploads/2016/08/map-2.png
Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.
Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй - по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.
Конечно, вы можете использовать для этого онлайн сервисы, но работают они плохо и не всегда показывают верное значение. Поэтому пользуемся опять curl.
Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:
curl -I https://сайт
Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:
В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.
Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:
curl -I https://сайт
Затем отправим полученную сумму с заголовком:
curl -I --header "If-None-Match: "58615db8-19034"" https://сайт
И снова мы должны получить ответ 304, страница не изменена.
Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:
curl -I https://сайт --header "Accept-Encoding: gzip"
В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.
В этой статье мы рассмотрели как выполняется проверка ответа сервера и проверка http заголовков, это может быть очень полезно для аудита технической стороны вашего сайта, а также для решения определенных проблем. Надеюсь, изложенная в статье информация была вам полезной.
Основатель и администратор сайта сайт, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux интересуюсь всем, что связано с информационными технологиями и современной наукой.
