Заголовки HTTP используются для "общения" браузера и web-сервера, например, когда браузер запрашивает какой-либо документ, он посылает заголовок GET, а когда сервер возвращает тип документа, то он делает это ни как-нибудь, а в заголовке Content-type.

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

Итак, приведем список и краткое описание основных заголовков HTTP.

Заголовок Accept

Заголовок Accept предназначен для информирования сервера о типах данных, которые поддерживаются клиентом (браузером). В этом заголовке браузер перечисляет, какие типы документов он "понимает". Пере-
числение идет через запятую.

Используется переменная окружения HTTP_ACCEPT. Пример использования:

Accept: text/html, text/plain, image/jpeg

В последнее время вместо списка указывается значение *.*, что означает "все типы".

Заголовок Content-type

Данный заголовок предназначен для идентификации типа передаваемых данных. При этом заголовок Content-type использует переменную окружения CONTENT_TYPE. Обычно для этого заголовка указывается значение application/x-www-form-urlencoded. Таким образом, указывается формат, в котором все управляющие символы (т.е. символы, не являющиеся алфавитно-цифровыми) специально кодируются. О некоторых других MIME-типах вы можете узнать .

Это тот самый формат передачи, который используется методами GET и POST .

Довольно распространен и другой формат, multipart/form-data.

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

Пример: Content-type: text/plain

Заголовок Content-length

Этот заголовок содержит строку, в которой записана длина передаваемых данных в байтах при использовании метода передачи POST. За заголовком закреплена одноименная переменная CONTENT_LENGTH.

Если задействуется метод GET, то этот заголовок отсутствует, и значит, переменная окружения не устанавливается.

Заголовок Cookie

В этом заголовке хранятся все Cookies . Данный заголовок использует переменную окружения HTTP_COOKIE. Для установки Cookies используется заголовок Set-Cookie.

Заголовок GET

Об этом заголовке мы упоминали ранее.

Заголовок GET использует следующие переменные окружения:

• REQUEST_URI - запрашиваемый идентификатор ресурса;
• QUERY_STRING - передаваемые сценарию параметры;
• REQUEST_METHOD - метод передачи информации. В данном случае эта переменная будет содержать значение GET.

Заголовок Location

Получив заголовок Location вместе с указанным в нем URL, сервер немедленно переходит по указанному URL, не дожидаясь, пока тело документа загрузится:

Пример: Location: http://www.somehost.com/

Заголовок POST

Этот заголовок использует те же переменные окружения, что и заголовок GET (переменная REQUEST_METHOD содержит значение POST). Напомним, что данные методом POST можно передавать в конце заголовков.

Напомним формат заголовка POST: POST сценарий?параметры HTTP/1.0

Заголовок Pragma

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

Пример заголовка: Pragma: no-cache

Заголовок Server

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

Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b Dav/1.0.3 PHP/4.3.0 mod_perl/1.26 configured

Заголовок Referer

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

Заголовок User-Agent

Содержит версию браузера. Например: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux).

Переменная окружения: HTTP_REFERER.

Некоторые комментарии по HTTP-заголовкам

Мы ознакомились с названиями заголовков и соответствующим им переменным окружения.

Необходимо помнить основные приципы:

• Все символы в верхнем регистре;
• В начале имен добавляется HTTP_
• Символы "-" заменяются знаком подчеркивания "_".

Передача заголовков HTTP в PHP

В PHP есть встроенные функции для работы с заголовками HTTP.

Для передачи заголовков HTTP предназначена функция header()

Приведем практические примеры:

header (" Content-type: text/plain " );
?>

header ("Location: http://www.example.com/" ); /* Производит перенаправление браузера на другой ресурс */

/* Внимание! Убедитесь, что код, расположенный ниже не исполняется */
exit;
?>

// Date in the past
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT" );

// always modified
header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" ) . " GMT" );

// HTTP/1.1
header ("Cache-Control: no-store, no-cache, must-revalidate" );
header ("Cache-Control: post-check=0, pre-check=0" , false );

// HTTP/1.0
header ("Pragma: no-cache" );
?>

URL:
User-Agent:
	Ваш браузер Google Chrome Mozilla Firefox Opera Internet Explorer Safari YandexBot YandexMobileBot GoogleBot GoogleBot-Mobile Mail.RU_Bot BingBot Android Webkit Browser Chrome for Android Opera Mobile BlackBerry IE Mobile Очистить (пустой) Можно выбрать User-Agent из списка
Referer:
	Показать html-код страницы

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

▼ Для справки: коды http-ответов сервера ▼

URL - Единый указатель ресурса (англ. Uniform Resource Locator, URL) - единообразный локатор (определитель местонахождения) ресурса. URL служит стандартизированным способом записи адреса ресурса в сети Интернет.

User Agent - это клиентское приложение, использующее определённый сетевой протокол. Термин обычно используется для приложений, осуществляющих доступ к веб-сайтам, таким как браузеры, поисковые роботы (и другие «пауки»), мобильные телефоны и другие устройства. При посещении веб-сайта клиентское приложение обычно посылает веб-серверу информацию о себе. Это текстовая строка, являющаяся частью HTTP запроса, начинающаяся с User-agent: или User-Agent:, и обычно включающая такую информацию, как название и версию приложения, операционную систему компьютера и язык. У «пауков» эта строка часто содержит URL и email-адрес, по которым веб-мастер может связаться с оператором «паука».

Referer (от ошибочного написания англ. referrer - отсылающий, направляющий) - в протоколе HTTP один из заголовков запроса клиента. Содержит URL источника запроса. Если перейти с одной страницы на другую, referer будет содержать адрес первой страницы. Часто на HTTP-сервере устанавливается программное обеспечение, анализирующее referer и извлекающее из него различную информацию. Так, например, владелец веб-сайта получает возможность узнать, по каким поисковым запросам, как часто и на какие именно страницы попадают люди. Если HTTP-клиент загружает с сервера картинку, представленную на какой-либо странице, то referer будет содержать адрес этой страницы. Некоторые HTTP-серверы перед выдачей картинки анализируют referer и не показывают картинку, если запрос приходит с другого сайта (а, например, показывают маленькое изображение-заглушку). Любопытно, что написание английского слова referrer как referer - популярная ошибка. Настолько популярная, что вошла в официальные спецификации протокола HTTP.

Заголовки HTTP (англ. HTTP Headers) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

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

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

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

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

• 100 Continue («продолжай») - сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
• 101 Switching Protocols («переключение протоколов») - сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Upgrade. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
• 102 Processing («идёт обработка») - запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

2xx Успех

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

• 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 Перенаправление

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI. По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход. Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии 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 («перемещено временно»), 302 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 заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx Ошибка клиента

Класс кодов 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 («условие ложно») - возвращается, если ни одно из условных полей заголовка (If-Match и др., см. RFC 7232) запроса не было выполнено. Появился в HTTP/1.1.
• 413 Request Entity Too Large («размер запроса слишком велик») - возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
• 414 Request-URL Too Long («запрашиваемый 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 «слишком много запросов») - клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком 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 градус по Фаренгейту». Был добавлен в стандарт 21 декабря 2015.

5xx Ошибка сервера

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

Список заголовков HTTP в ответах сервера:

Заголовок

Назначение	Пример
Accept-Ranges	Cообщает клиенту о том, что он может запрашивать данные с сервера фрагментами, указывая их смещение в байтах	Accept-Ranges: bytes Accept-Ranges: none
Age	Возраст документа в кэше прокси в секундах	Age: 12
Allow	Список поддерживаемых методов.	Allow: GET, HEAD
Cache-Control	Основные директивы для управления кэшированием.	Cache-Control: no-cache Cache-Control: no-store Cache-Control: max-age=3600 Cache-Control: max-stale=0 Cache-Control: min-fresh=0 Cache-Control: no-transform Cache-Control: only-if-cached Cache-Control: cache-extension
Connection	Заголовок используется для управления текущим соединением.	Connection: close Connection: keep-alive Connection: Upgrade
Content-Encoding	Способ кодирования содержимого документа при передаче.	Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: identity Content-Encoding: br
Content-Language	Один или несколько естественных языков содержимого документа.	Content-Language: en, hi, ru
Content-Length	Размер передаваемого документа в байтах.	Content-Length: 7529
Content-Location	Указывает альтернативное расположение для возвращаемого документа.	Content-Location: /index.html
Content-MD5	MD5-сумма в кодировке Base64 документа для проверки целостности.	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	Байтовые диапазоны передаваемого документа если возвращается фрагмент.	Content-Range: bytes 88080384-160993791/160993792
Content-Type	Указывает mime-type документа и кодировку в которой передаётся текст	Content-Type: image/gif Content-Type: text/html;charset=utf-8
Content-Version	Информация о текущей версии документа.
Date	Дата генерации ответа сервера.	Date: Sun, 30 Oct 2016 17:11:31 GMT
ETag	Уникальный идентификатор документа, используемый при кэшировании в браузере.	ETag: "56d-9989200-1132c580"
Expires	Дата предполагаемого истечения срока актуальности документа.	Expires: Sun, 30 Oct 2017 17:11:31 GMT
Last-Modified	Дата последней модификации документа.	Last-Modified: Mon, 26 Sep 2016 02:02:31 GMT
Link	Указывает на логически связанный с документом ресурс аналогично тегу в HTML.	Link: ; rel="https://api.w.org/"
Location	URI по которому клиенту следует перейти. Заголовок используется для редиректа при .	Location: https://сайт/tools/httpheaders.php
Pragma	Используется только для обратной совместимости с HTTP/1.0 клиентами.	Pragma: no-cache
Retry-After	Дата или время в секундах после которого можно повторить запрос.	Retry-After: Wed, 21 Oct 2015 07:28:00 GMT Retry-After: 120
Server	Список названий и версий веб-сервера и его компонентов с комментариями.	Server: nginx/1.10.1
Set-Cookie	Заголовок используется для установки и обновления cookie в браузере	Set-Cookie: qwerty=219ffwef9w0f; Domain=сайт; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
Status	Заголовок, определяющий код состояния ответа HTTP.	Status: 200 OK
Trailer	Список полей, имеющих отношение к кодированию сообщения при передаче.	Trailer: Expires
Transfer-Encoding	Список способов кодирования, которые были применены к документу для передачи.	Transfer-Encoding: chunked
Upgrade	Список предлагаемых клиентом протоколов. Сервер указывает один протокол.	Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
Vary	Список полей из запроса, которые были приняты сервером во внимание.	Vary: * Vary: Accept-Encoding
Via	Список версий протокола, названий и версий прокси-серверов, через которых прошло сообщение.	Via: 1.0 fred, 1.1 сайт
Warning	Код, агент, сообщение и дата, если возникла критическая ситуация.	Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"

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

заголовки?

«Протокол передачи гипертекста» - именно так переводится Благодаря его существованию, возможна связь «клиент-сервер». Если объяснить простыми словами, пользователь браузера посылает запрос, инициируя соединение с сервером. Последний, по умолчанию, ждет запрос от клиента, обрабатывает его и посылает обратно итоговую информацию или ответ. В поисковой строке пользователь «вбивает» адрес сайта, который начинается с http:// и получает результат в виде открывшейся страницы.

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

В общем, http заголовки достаточно эффективные. Их не видно в HTML-кодировании, они отправляются перед запрашиваемыми сведениями. Многие заголовки автоматически высылаются сервером. Для того чтобы его отослать на языке PHP, следует воспользоваться функцией header.

Взаимодействие браузера и сайта

Схема взаимодействия браузера и сайта достаточно простая. Так, http заголовок начинает строку запроса, который далее посылается серверу. В ответ приходит нужная клиенту информация. Между прочим, http протокол уже семнадцать лет - самый используемый в Интернете. Он простой, надежный, работает быстро и гибко. Главная задача http - запрос сведений с web-сервера. Клиентом является браузер, а сервером - ligthttp, apache, nginx. Если соединение между ними произошло успешно, сервер в ответ на запрос получает нужные сведения. Информация http содержит текстовые, звуковые файлы, видео.

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

• стартовой строки (тип сообщения);
• заголовков (параметры сообщения);
• тела информации (сообщение, которое отделяется пустой строчкой).

Стартовая строка - обязательный элемент запроса поля заголовков http. Структура запроса пользователя состоит из трех основных частей:

1. Метод. С его помощью указывается тип запроса.
2. Путь (path). Это строка URL, которая следует за доменом.
3. Используемый протокол. Он состоит из версии protocol и http.

Современные браузеры используют версию 1.1. Далее следуют заголовки в формате "Имя: значение".

HTTP-кэширование

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

Кэш имеет браузер клиента, промежуточный шлюз и прокси-сервер. Перед тем как отправить сообщение по URL, браузер проверит наличие объекта в кэше. Если объекта нет, запрос передается следующему серверу, где проверяется кэширование http заголовков на сервере nginx. Шлюзы и прокси используются разными пользователями, поэтому кэш является разделяемым.

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

Описание http заголовков

Одними из самых главных механизмов кеша считаются 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:

• Firebug. Просмотреть заголовки можно во вкладке net (сеть), где выбрать all (все). Этот плагин обладает функциями, которые будут полезны веб-разработчику.
• Live http headers. Простой плагин, предназначенный для просмотров http заголовков. С его помощью вручную можно сгенерировать запрос.
• Пользователи Ghrome легко увидят заголовки, если нажмут кнопку настроек, выберут инструменты разработчика (net works).

Когда плагины будут установлены, запустите их и браузера.

Методы запросов

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

• Метод GET. Его используют для запроса информации с ресурса. Именно с него начинаются все действия.
• POST. С его помощью происходит отправка данных. Например, сообщение в социальной сети или комментарий, браузер помещает в тело POST-запроса и отправляет серверу.
• HEAD. Метод имеет сходства с первым, но выполняет легкую функцию. Он запрашивает только мета-данные, исключая из ответа сообщение. Методом пользуются, если хотят получить информацию о файлах без скачивания. Его используют, если хотят проверить работоспособность ссылок на сервере.
• PUT. Загружает данные на URL. Передает большие объемы данных.
• OPTIONS. Работает с конфигурациями сервера.
• URI. Идентифицирует ресурс и содержит в себе URL.

Структура http ответа

Сервер отвечает на запросы клиента длинными сообщениями. Ответ состоит из нескольких строк, в которых указывается версия протокола, код статуса сервера (200). Он говорит о том, что изменилось на сервере за время обработки поступившего запроса:

1. Статус «двести» указывает на успешную обработку информации. После этого сервер отправляет документ клиенту. Остальные строчки запроса указывают на другую информацию о передаваемых сведениях.
2. Если файл не найден или не существует, сервер посылает клиенту код 404, его еще называют ошибкой.
3. Код 206 указывает на частичное скачивание файла, которое можно возобновить спустя время.
4. Код 401 свидетельствует об отказе в авторизации. Это означает, что запрашиваемая страница защищена паролем, который следует ввести для подтверждения входа.
5. О запрещенном доступе, говорит код 403. Запреты на просмотры, скачивание файлов или видео - распространенный ответ в Интернете.
6. Существуют также другие версии кодов: временное перемещение запрашиваемого файла, внутренняя ошибка сервера, окончательное перемещение. В этом случае, пользователь будет перенаправлен. Если появился код 500, это означает, что в работе сервера появились сбои.

URL - что это?

URL - это сердце веб-общения между клиентом и сервером. Запрос обычно отправляется через URL - единый указатель ресурсов. Структура запроса url очень проста. Она состоит из нескольких элементов: протокол http (заголовок), hoot (адрес сайта), port, resourte path и query.

Протокол доступен также для безопасного соединения https и обмена информацией. URL-адрес содержит информацию о размещении конкретного сайта в Интернете. Адрес включает в себя имя домена, путь к странице, а также ее название.

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

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

• Обозначайте сроки годности файлов и документов, с учетом обновлений. Статистическая информация указывается в больших значениях max-age.
• Отдельный документ должен быть доступен лишь по одному URL.
• Если обновляете файл, который будет скачиваться пользователем, измените его имя и ссылку на него. Это гарантирует скачивание нового, а не устаревшего документа.
• Заголовки Last-Modified должны соответствовать настоящей дате последних изменений содержания. Не следует пересохранять страницы и документы, если не будете их менять.
• Используйте POST-запросы лишь там, где это нужно. Сведите к минимуму работу с SSL.
• Заголовки перед отправкой сервером следует проверять плагином REDbot.

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

В упомянутой выше статье помимо теоретической информации были приведены также листинги HTTP-заголовков, используемых браузером при запросе главной страницы сайта ya.ru и содержащихся в ответе веб-сервера на соответствующий запрос. Но гораздо интереснее (и полезнее) посмотреть, чем отвечает ваш сервер на запросы браузером ваших страничек. Позже, при создании "умных" HTML-страниц это станет ключом к пониманию принципов активного взаимодействия пользователя и сайта.

В качестве инструмента для просмотра HTTP-заголовков я предлагаю использовать плагин к браузеру FireFox LiveHTTPHeaders . Установить его можно так: Инструменты - Дополнения - Поиск дополнений, ищем по слову "headers", устанавливаем LiveHTTPHeaders. После перезагрузки браузера появится новая функция: Инструменты - Просмотр HTTP-заголовков.

Предлагаю опробовать плагин на странице, созданной на предыдущем уроке . Открываем окно "Просмотр HTTP-заголовков", жмем "очистить", чтобы убрать появившиеся заголовки (при запросе домашней страницы браузера и т.п.). Далее делаем запрос страницы, например, http://test-domain2/. В окне заголовков появились заголовки от запросов браузера и от ответов веб-сервера:

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

Чтобы сформировать веб-страницу браузер делает несколько запросов к веб-серверу: непосредственно кода страницы, файлов CSS-стилей, изображений и т.п. Все эти запросы отражены в форме. Первым идет запрос HTML-страницы:

GET / HTTP/1.1 Host: test-domain2 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache

на что сервер ответил:

HTTP/1.1 200 OK Date: Fri, 04 Jun 2010 08:52:09 GMT Server: Apache Last-Modified: Wed, 26 May 2010 11:34:58 GMT Etag: "3000000002878-20ca-4877da9e71c80" Accept-Ranges: bytes Content-Length: 8394 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8

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

Основные заголовки ) - должны включаться в любое сообщение клиента и сервера.

Request Headers (рус. Заголовки запроса ) - используются только в запросах клиента.

Response Headers (рус. Заголовки ответа ) - только для ответов от сервера.

Entity Headers (рус. Заголовки сущности ) - сопровождают каждую сущность сообщения.

Энциклопедичный YouTube

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

Общий формат

• Название параметра должно состоять минимум из одного печатного символа (ASCII -коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.
• Значение может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).

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

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

Пример с многострочными значениями и одинаковыми именами заголовков (обратите внимание на регистр символов и пробелы):

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 исторически используется три формата:

• Fri, 04 Jul 2008 08:42:36 GMT - RFC 822 .
• Friday, 04-Jul-08 08:42:36 GMT - RFC 850 .
• Fri Jul 4 08:42:36 2008 - результат функции asctime() языка ANSI C .

Сейчас рекомендуется использовать только первый формат по 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 байт):

• bytes=0-255 - фрагмент от 0-го до 255-го байта включительно.
• bytes=42-42 - запрос одного 42-го байта.
• bytes=4000-7499,1000-2999 - два фрагмента. Так как первый выходит за пределы, то он интерпретируется как « 4000-4999 ».
• bytes=3000-,6000-8055 - первый интерпретируется как « 3000-4999 », а второй игнорируется.
• bytes=-400,-9000 - последние 400 байт (от 4600 до 4999), а второй подгоняется под рамки содержимого (от 0 до 4999) обозначая как фрагмент весь объём.
• bytes=500-799,600-1023,800-849 - при пересечениях диапазоны могут объединяться в один (от 500 до 1023).

Работа с заголовками

Заголовки в HTML

Язык разметки 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" > ...