Скала

Содержание

Протокол HTTP — HTML, CSS, JavaScript, Perl, PHP, MySQL: Weblibrary.biz

На 17-м занятии, «Введение в CGI», мы уже говорили о том, как осуществляется взаимодействие между Web-броузером (таким как Netscape или Internet Explorer) и Web-сервером (например, Apache или IIS) с помощью протокола CGI. Рассматриваемый нами процесс был несколько упрощен. Теперь, после того как вы узнали, что такое CGI, пришло время разобраться с протоколами взаимодействия броузера и сервера более подробно. Чуть позже на этом же занятии вы познакомитесь с некоторыми методами управления этим взаимодействием, позволяющими решать ряд интересных задач.

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

Документы стандартов, в которых описаны протоколы, используемые в internet, называются Request For Comments, или RFC.

Эти документы, поддерживаемые организацией Internet Engineering Task Force (IETF), можно просмотреть в Web no адресу http://vww. ietf.org. Протокол HTTP описан в документах RFC 1945 и RFC 2616. Однако имейте в виду, что эти документы рассчитаны на подготовленных пользователей.

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

По строке GET можно судить о том, с какого адреса URL вы пытаетесь получить документ и какую версию протокола используете. В данном случае вы используете версию 1.0 протокола HTTP.

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

Строки Accept определяют, какие виды данных вы хотели бы принимать с помощью этого соединения. Символы */* в конце первой строки Accept означают, что вы не прочь принимать любые виды данных. Следующая строка (iso-8859-l и остальные) определяет, какое кодирование символов может быть использовано для документа. Строка Accept-Encoding: gzip в данном случае означает, что для сжатия данных, получаемых от сервера, с целью их быстрой передачи может быть использована утилита gzip (GNU Zip). Наконец, строка Accept-Language говорит о том, какие языки приемлемы для этого броузера: английский (США), английский (Великобритания), немецкий, французский и т.д.

В строке Host указывается имя сервера, обслуживающего Web-узел. Благодаря виртуальности обслуживания (пояснения ниже) это имя может отличаться от имени компьютера в URL.

Наконец, броузер идентифицирует себя для Web-сервера как Mozilla/4.51 [en]C-c32f404p (WinNT; U). В Web-терминологии броузер называется

пользовательским агентом (user agent).

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

За ответом следует содержимое, запрашиваемой вами страницы.

Строка GET в данном случае означает, что сервер собирается передать броузеру Web-страницу. Код возврата 200 свидетельствует о том, что «все» прошло прекрасно. При этом сервер не забывает сказать «несколько слов о себе», идентифицируя себя с помощью строки Server: в данном случае у нас «работает» Web-сервер Netscape-Enterprise/3.5.1G.

Строка Content-Length означает, что броузеру было передано 2222 байта. На основе этих данных ваш броузер теперь сможет вычислить процент завершения загрузки страницы. Строка Content-Type определяет тип посланной обратно страницы. Для HTML-страниц указывается тип text/html, а для изображений может быть установлен тип image/jpeg.

По дате Last-Modified броузер может «судить» о том, была ли изменена страница с момента ее последней загрузки. Большинство Web-броузеров помещает загруженные ранее страницы в локальную кэш-память, чтобы при повторном обращении к этой странице не нужно было ее снова и снова загружать из Internet. При этом полученная от сервера дата сравнивается с датой сохраненной копии, находящейся в кэш-памяти. Если страница на сервере не была изменена, броузер использует локальную копию.

Пример: получение страницы вручную

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

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

Если у вас установлена система UNIX, то в ее поставку обязательно должна входить утилита telnet. Если вы используете Microsoft Windows, то программа telnet автоматически инсталлируется при установке протокола TCP/IP. Чтобы запустить Telnet-клиент, просто используйте команду Выполнить из системного меню Пуск. Если же у вас не установлена программа telnet или вы работаете в системе Macintosh, попробуйте поискать Telnet-клиент в Internet и загрузить его на свой компьютер.

Подключение к Web-серверу с помощью telnet осуществляется следующим образом:

где www.webserver.com — имя Web-сервера, а 80 — номер порта, к которому вы хотите подключиться (именно этот порт обычно используется Web-серверами для установки соединения по протоколу HTTP). Если ваша программа telnet имеет графический интерфейс, то, возможно, придется установить эти значения в специальном диалоговом окне.

После подключения Telnet-клиента вы можете не получить никакого символа приглашения на ввод или сообщения о факте подключения. Не беспокойтесь: это нормальная ситуация. Сервер HTTP ожидает, что клиент «заговорит» первым, поэтому от сервера и не ожидается никакого приглашения. В системе UNIX вы получите сообщение, которое может иметь следующий вид:

Работая в других операционных системах (Windows или Macintosh), вы не увидите подобного сообщения.

Теперь нужно аккуратно и побыстрее ввести следующее:

После ввода этой строки нажмите клавишу <Enter> дважды. Web-сервер должен ответить обычным HTTP-заголовком и страницей верхнего уровня для данного Web-узла, а затем закрыть сеанс связи.

Пример: получение нетекстовой информации

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

Функция header в CGl-модуле информирует броузер о том, данные какого типа он будет получать. Для этого используется заголовок MIME Content-Type, который описывает содержимое данных, следующих за ним. В результате броузер сразу «узнает», что ему нужно делать с полученными данными.

По умолчанию функния header посылает броузеру заголовок Content-Type типа text/html. И броузер «понимает», что за заголовком следует содержимое, представляющее собой текст в формате HTML.

Предупредив броузер о типе получаемых данных, вы можете таким образом управлять способом обработки этих данных броузером. Данные могут выводиться в виде изображений, звука, передаваться дополнительному модулю броузера (browser plug-in) или внешней программе, запускаемой броузером.

Чтобы заставить функцию header послать нечто, отличное от обычного заголовка типа text/html, используйте ключ -type:

Среди тех типов MIME, указываемых в заголовке Content-Type, которые обычно посылаются броузеру, чаще других встречаются text/plain (для текстов, не подлежащих интерпретации броузером), image/gif и image/jpeg (для GIF- и JPEG-изображений), а также application/аррname (для данных, относящихся к конкретному приложению с именем аppnameе). Есть еще специальный тип MIME заголовка Content-Type application/octet-steam, означающий передачу необработанных двоичных данных, которые броузер должен просто сохранить в файле.

Описанные выше типы данных пригодятся вам на случай, если вы захотите создать Web-узел, показывающий «изображение дня» или рекламу Web-страниц. Ежедневное изменение Web-странии для отражения нового образа может превратиться в проблему. А если при этом вас не будет на месте, кто обновит «изображение дня»? Чтобы существенно облегчить себе жизнь, можно создать статическую HTML-страницу и написать CGI-программу на языке Perl, которая бы автоматически каждый день выводила новое изображение.

Для решения проблемы поместите следующий HTML-код в тело Web-страницы:

В приведенном фрагменте HTML-кода обратите внимание, что в дескрипторе <IMG> указана CG1-программа, а не GIF- или JPEG-изображение. Затем вам потребуется папка с изображениями, которых должно хватить хотя бы на месяц. Вы можете использовать любые изображения, главное, чтобы их файлы имели расширение .jpeg. К тому же заметьте, что эту программу можно легко адаптировать для изображений в формате GIF.

CGI-программа daily_image.cgi может иметь вид, представленный в листинге 20.1.

Проведем анализ программы.

Строка 7. В этой строке задается каталог, в котором располагаются файлы изображений. Этот каталог можно заменить другим, соответствующим физическому расположению ваших файлов изображений.
Строка 8. Как ни странно, но, поскольку эта CGI-программа не выдает никакого текста и поскольку HTML-страница, в которую она встроена, не отображает результат в виде текста, вы не можете просто выводить сообщения об ошибках. Если каталог $imagedir невозможно будет открыть, то будет отображен .jpg-файл, имя которого содержится в переменной $error.
Строки 10—16. Эта процедура выводит изображения в стандартный выходной поток, который будет направлен броузеру. На Windows-платформах поток STDOUT рассматривается как текстовый файл, значит, при выводе .jpg-файла в поток STDOUT изображение будет искажено. Поэтому, чтобы сделать дескрипторы STDOUT и IMAGE бинарными, используется функция binmode. Под управлением системы UNIX нет необходимости в использовании функции binmode, но ее присутствие не повредит. Обратите внимание на строку 12: если изображение не удается открыть, нет смысла в выводе сообщения об ошибке, поэтому просто выполняется выход из программы.
Строка 19. Эта строка выводит стандартный HTML-заголовок, за исключением того, что в строке Content-Type вместо обычного типа text/html используется image/jpeg.
Строка 25. Открывается каталог с изображениями для чтения. Если каталог с изображениями не открывается, то вызывается функция display_image(), которой через переменную $error передается имя файла с изображением ошибки.
Строка 26. Эта строка посложнее других, поэтому на ней стоит остановиться. Сначала содержимое каталога читается с помощью функции readdir. Затем из списка извлекаются имена файлов с расширением .jpg. Наконец, полученный список сортируется и присваивается переменной в @jpegs.

HTTP протокола / HTML / JSON

Протокола НТТРА является объектно-ориентированным протоколом, принадлежащим к прикладному уровню, который подходит для распределенных информационных систем гипермедиа благодаря своему простому и быстрому способу. В настоящее время шестое издание HTTP / 1. 0 используется в настоящее время, и стандартизация HTTP / 1.1 идет полным ходом, и были предложены рекомендации HTTP-Нг.

Протокол HTTP работает над архитектурой клиент-сервер. Браузер отправляет все запросы на сервер HTTP в качестве сервера HTTP в качестве клиента HTTP. Веб-сервер передает информацию ответа клиенту на основании полученного запроса.

Основные особенности протокола HTTP:

Простой и быстрый: Когда клиент запрашивает услугу на сервер, просто отправить метод запроса и путь. Методы запроса обычно используются с GET, HEAD, POST. Каждый метод определяет, что клиент отличается от типа сервера. Благодаря простому протоколу HTTP, размер программы сервера HTTP мал, поэтому скорость передачи данных быстро.
Гибкость: Протокол HTTP позволяет передавать любой тип объекта данных. Тип передаваемого отмечен Content-Type.
Нет связи: бессмысленный смысл не в том, что он ограничивается одним запросом на соединение. Сервер обрабатывает запрос клиента и получает ответ клиента, он отключен. Таким образом, можно сэкономить время передачи.
Нет Статус: Протокол HTTP не является протоколом без гражданства. Там нет состояния означает, что протокол не имеет возможностей памяти для обработки транзакций. Отсутствие государственных средств, что, если последующая обработка требует предыдущей информации, он должен быть повторно передан, что может привести к увеличению объема данных, передаваемых каждый раз. С другой стороны, его ответ быстрее, если сервер не требует предыдущей информации.

Поддержка B / S и режим C / S.

HTTP (протокол передачи гипертекста) представляет собой протокол на основе запроса и режим ответа, который часто на основе TCP. Механизм непрерывного подключения приведен в HTTP1.1, и большинство веб-разработки является веб-приложение, которое строится на протоколе HTTP.

Формат HTTP URL выглядит следующим образом:http://www.x.com:8080/news/index.html?ID=24618&page=1

HTTP Это представляет собой веб-страницу, которая является протокол HTTP, «//» за «HTTP» разделитель.
www.x.comУказывает доменное имя юридического или IP-адрес.
С именем домена, порт, доменное имя и порт используется в качестве разделителя. Порт не является частью, которая должна быть частью URL, и если часть порта опущен, по умолчанию порт 80 будет использоваться.
/New/index.html Указывает путь запроса ресурсов
От «?» Начиная с раздела параметров, параметры могут позволить несколько параметров, параметры и параметры использования «и» в качестве разделителей. Конечно, нет никаких параметров.

Запрос HTTP-состоит из строки запроса, заголовок запроса (заголовок), заготовки и данных запроса.

[Получить пример запроса]

GET /562f25980001b1b106000338 HTTP/1.1

Host img.mukewang.com

User-Agent Mozilla/5.0 (windows NT 10.0; WOW64) AppleWebKit /537.36 (KHTML, like Gecko) Chrome/51.0.2704.106

Accept image/webp,image/*，*/*；q=0.8

Referer http://www.imooc.com/

Accept-Encoding gzip,deflate, sdch

Accept-Language zh-CN,zh;q=0. 8

[Пример запроса POST]

POST / HTTP/1.1

HOST:www.wrox.com

User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Connect-Type:application/x-www-form-urlencoded

Content-Length:40

Connection:Keep-Alive

name=Professional %20Ajax&publisher=Wiley

GET запрашивает указанную информацию страницы и возвращает результат ответа.
POST отправляет данные в указанный ресурс для обработки запросов (например, формы представления или загружаемых файлах)
Заголовок сообщения ответа ГОЛОВА
PUT запрос сервера Магазин ресурс
Удаление запроса сервера Удаление ресурсов

Ответ HTTP также состоит из четырех частей: строки состояния, заголовок сообщения, пустая строка и тело ответа.

HTTP/1.1 200 OK

Date: Sat, 31 Dec 2005 23:59:59 GMT

Connect-Type: text/html;charset=ISO-8859-1

Connect-Length：122

<html>

<head>

<title>Wrox Homepage</title>

</head>

<body>

<!—body goes here—>

</body>

</html>

Положение дел

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

1хх: Инструкция Информация — Указывает, что запрос был получен и процессы.
2xx: Успех — означает, что запрос был успешно получен, понят, и принимает.
3xx: Перенаправление — Для того, чтобы выполнить запрос, дальнейшее действие должно быть обработано.
4XX: ошибка клиента — запросы на грамматические ошибки или запросы не могут быть реализованы.
5xx: Ошибка сервера — сервер не в состоянии осуществлять юридические запросы.

Общий код состояния, описание состояния, описание (назад):

200 ОК // клиент успеха запрос
400 Bad Request // Клиент имеет синтаксическую ошибку и не может быть понят сервером.
401 несанкционированной // Запроса несанкционированные, этот статус-код должен быть использован с заголовком WWW-Authenticate.
403 Forbidden // сервер принимает запросы, но отказался предоставить услуги
404 Not Found // Запрос ресурсов не существует, EG: Введите неправильный URL
500 Ошибка Internet Server // Сервер непредсказуемо ошибка
503 Сервер UNAVAILABLE / / Сервер не может обработать запрос клиента, который может вернуться в нормальное состояние через некоторое время

См рисунок выше, в ответ на заголовок. Как правило, мы должны обратить внимание на Content-Type, он определяет HTML (Текст / HTML) типа MIME, тип кодировки UTF-8.
Тело ответа является содержанием ресурса, возвращаемого сервером.

Ниже шаг запроса HTTP / ответ:

Подключение клиента к веб-серверу

HTTP-клиент, как правило, браузер, установить соединение TCP сокет с HTTP порт веб-сервера (по умолчанию 80).

Запрос HTTP Отправить

С гнездом TCP, клиент посылает сообщение с запросом на текст на веб-сервер, и сообщение запроса состоит из строки запроса, заголовка запроса, заготовки, и запроса данных 4.

Сервер получает запросы и возвращает HTTP-ответ

Веб-сервер разбор запроса, позиционирование запроса ресурсов. Сервер записывает копию ресурса в сокет TCP, прочитан клиентом. Ответ состоит из государственной линии, головы ответа, пустой строки, и данных отклика 4.

разрывать соединение TCP

Если режим подключения находится близко, сервер активно отключает соединение TCP, клиент пассивно закрыт, отпустите соединение TCP; если режим подключения хранится, соединение останется некоторое время, и запрос может продолжать получать запрос.

Клиентский сервер, разбирающий HTML контент

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

Например: введите URL в поле Адрес браузера, следуйте следующим процедурам после нажатия:

Браузер запрашивает DNS-сервер для разрешения IP-адреса, соответствующий доменному имени в URL;
После того, как IP-адрес анализируется, соединение TCP устанавливается в соответствии с IP-адресом и портом 80 по умолчанию и сервером;
Браузер выдает HTTP-запрос для файла чтения (файлы, соответствующие задней части доменного имени в URL), который отправляется на сервер в качестве данных третьего пакета трехколенного рукопожатия TCP;
Сервер отвечает на запрос браузера и отправляет соответствующий HTML-текст в браузер;
Отпустите TCP соединение;
Браузер решает текст HTML и отображает содержимое.

https://www.w3school.com.cn/html/index.asp

Сердце: Фонд, Элемент, Собственность, Ссылка, Форма, URL

https://www.w3school.com.cn/json/index.asp

Протокол HTTP — Инструменты — Дока

Кратко

Секция статьи «Кратко»

HTTP был разработан как протокол обмена данными между веб-сервером и веб-браузером. Это протокол прикладного уровня модели OSI, который используется для передачи между клиентом и сервером файлов HTML, CSS, JS, API, картинок, аудио, видео, введённых пользователем данных и прочего. Клиент (веб-браузер) отправляет серверу (веб-серверу) запросы и получает от него ответы. Сервер в рамках протокола HTTP практически всегда занимает пассивную позицию.

Как понять

Секция статьи «Как понять»

Есть три главных объекта, которые обмениваются сообщениями:

Клиент (user agent) — программа, которая отправляет запросы, получает и обрабатывает ответы от имени пользователя на устройстве пользователя, например, браузер.
Сервер (веб-сервер) — программа, которая работает на сервере, принимает и обрабатывает запросы от клиента, а затем отправляет ответы клиенту. Этой программой является веб-сервер.
Прокси (прокси-сервер) — программа, которая работает на сервере, пропускает через себя запросы и ответы и выступает в роли посредника между клиентом и сервером.

📚

Подробнее о веб-серверах читайте в статье «Веб-сервер».

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

Протокол HTTP не хранит состояние, поэтому количество соединений не приводит к существенному усложнению взаимодействия между объектами системы. Однако существует понятие сессии, с помощью которой можно передавать и хранить необходимые данные, относящиеся к конкретному сеансу связи. Данные сессии сохраняются на клиенте и на сервере. Например, доступен идентификатор сессии, который позволяет не проводить авторизацию клиента при каждом обращении к серверу.

🍪

Часто для хранения данных о сессии используются Cookie.

Прокси-серверы осуществляют сервисные функции:

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

🍪

Подробнее о разных атаках можно прочитать в статье «Безопасность веб-приложений».

Формат сообщения

Секция статьи «Формат сообщения»

HTTP-сообщение представляет собой обычный текст. Структура сообщения строго определена:

Стартовая строка;
Заголовки, передают сервисную информацию;
Тело сообщения, представляет данные в текстовом виде.

Тело сообщения — это опциональная часть сообщения, которая может отсутствовать. Например, для некоторых GET-запросов (то есть запросов со стороны клиента, в качестве метода получения данных для которого выбран метод GET) или для всех HEAD-запросов. Если тело сообщения присутствует, то это обозначается заголовками Content-Length или Transfer-Encoding.

Стартовая строка

Секция статьи «Стартовая строка»

Стартовая строка запроса содержит информацию о методе запроса, относительном адресе и версии протокола в формате Метод URI HTTP/Версия. Стартовая строка ответа содержит версию протокола, код и статус ответа сервера в формате HTTP/Версия Код Статус.

Когда браузер посылает запрос на открытие главной страницы сайта, стартовая строка запроса будет такой:

GET / HTTP/1.1
          GET / HTTP/1.1

Если страница существует и к ней есть доступ, то стартовая строка ответа будет такой:

HTTP/1.1 200 OK
          HTTP/1.1 200 OK

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

OPTIONS — используется для определения возможностей сервера по преобразованию данных.
GET — используется для получения данных от сервера.
HEAD — то же, что и GET, но не содержит тело в сообщении ответа.
POST — используется для отправки данных на сервер.
PUT — используется для добавления новых или изменения существующих данных на сервере.
PATCH — то же, что и PUT, но используется для обновления части данных.
DELETE — используется для удаления данных на сервере.
TRACE — возвращает запрос от клиента таким образом, что в ответе содержится информация о преобразованиях запроса на промежуточных серверах.
CONNECT — переводит текущее соединение в TCP/IP-туннель. Обычно этот метод используется для установления защищённого SSL-соединения.

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

1xx — обработка данных на сервере продолжается;
2xx — успешная обработка данных;
3xx — перенаправление запросов;
4xx — ошибка по вине клиента;
5xx — ошибка по вине сервера.

Самые популярные ответы сервера (коды состояния и статусы):

200 OK в случае успешной обработки запроса.
301 Moved Permanently если редирект используется на постоянной основе.
307 Temporary Redirect если редирект используется временно.
400 Bad Request если в запросе есть синтаксическая ошибка.
403 Forbidden если запрос успешный, но сервер его не может выполнить, поскольку пользователь не имеет достаточных прав.
404 Not Found если запрошенного ресурса не существует.
500 Internal Server Error если работа программы на сервере выдала ошибку.

Все возможные статусы описаны в реестре кодов, а так же на справочных ресурсах.

Использование заголовков

Секция статьи «Использование заголовков»

Заголовки делятся на четыре группы:

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

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

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

Приведём пример. Для экономии трафика часто используют сжатие данных: архивация данных перед пересылкой и разархивация после пересылки. Для этого применяют несколько алгоритмов сжатия. Например, часто применяется gzip, но наиболее интересным и современным является brotli.

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

Например, для того чтобы сообщить серверу о поддержке сжатия в форматах gzip, br или deflate, нужно использовать заголовок:

Accept-Encoding: gzip, br, deflate
          Accept-Encoding: gzip, br, deflate

Сервер для передачи данных в сжатом формате gzip должен послать заголовок:

Content-Encoding: gzip
          Content-Encoding: gzip

Тело сообщения

Секция статьи «Тело сообщения»

Формат данных тела сообщения может быть нескольких типов, которые закреплены в спецификациях HTTP-протокола различных версий (HTTP/1. 0 (стандарт RFC 1945), HTTP/1.1 (стандарт RFC 2616), HTTP/2 (черновик стандарта), HTTP/3 (черновик стандарта)). Чаще всего встречаются типы:

text/html.
application/json.
multipart/form-data.

На практике

Секция статьи «На практике»

Игорь Коровченко советует

Секция статьи «Игорь Коровченко советует»

Просмотр HTTP-сообщений из командной строки

Секция статьи «Просмотр HTTP-сообщений из командной строки»

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

Чтобы скачать главную страницу какого-то сайта (например, http://example. com), можно воспользоваться командой:

curl http://example.com
          curl http://example.com

В терминале вы увидите HTML-код страницы — это тело сообщения ответа. Существует возможность посмотреть и полные сообщения запроса и ответа, добавив ключ -v:

curl -v http://example.com*   Trying 93.184.216.34...* TCP_NODELAY set* Connected to example.com (93.184.216.34) port 80 (#0)> GET / HTTP/1.1> Host: example.com> User-Agent: curl/7.64.1> Accept: */*>< HTTP/1.1 200 OK< Age: 258083< Cache-Control: max-age=604800< Content-Type: text/html; charset=UTF-8< Date: Thu, 22 Jul 2021 15:42:57 GMT< Etag: "3147526947+ident"< Expires: Thu, 29 Jul 2021 15:42:57 GMT< Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT< Server: ECS (dcb/7F17)< Vary: Accept-Encoding< X-Cache: HIT< Content-Length: 1256<<!doctype html><html>* Connection #0 to host example.com left intact* Closing connection 0
          curl -v http://example. com
*   Trying 93.184.216.34...
* TCP_NODELAY set
* Connected to example.com (93.184.216.34) port 80 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Age: 258083
< Cache-Control: max-age=604800
< Content-Type: text/html; charset=UTF-8
< Date: Thu, 22 Jul 2021 15:42:57 GMT
< Etag: "3147526947+ident"
< Expires: Thu, 29 Jul 2021 15:42:57 GMT
< Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
< Server: ECS (dcb/7F17)
< Vary: Accept-Encoding
< X-Cache: HIT
< Content-Length: 1256
<
<!doctype html>
<html>
* Connection #0 to host example.com left intact
* Closing connection 0

В выводе команды curl символы *, > и < являются маркерами типа информации, отображённой в выводе команды. * используется для сервисной информации о соединении, > — для обозначения запросов клиента (клиентом является curl), < — для обозначения ответов сервера.

В первой части вывода содержится информация о процессе установления соединения через протокол TCP:

*   Trying 93.184.216.34...* TCP_NODELAY set* Connected to example.com (93.184.216.34) port 80 (#0)
          *   Trying 93.184.216.34...
* TCP_NODELAY set
* Connected to example.com (93.184.216.34) port 80 (#0)

Curl пытается соединиться с сетевым устройством с IP-адресом 93.184.216.34, поскольку именно этот адрес соответствует домену example.com. Строка после слова Connected... curl указывает, что соединение установлено. В последней части curl выводит информацию о прекращении соединения:

* Connection #0 to host example.com left intact* Closing connection 0
          * Connection #0 to host example.com left intact
* Closing connection 0

Вторая часть вывода — полное HTML-сообщение запроса со стартовой строкой и заголовками (тело сообщения отсутствует):

> GET /HTTP/1. 1 — Стартовая строка с методом запроса, адресом внутри сайта и версией протокола.
> Host: example.com — Заголовок с указанием хоста, на котором работает веб-сервер.
> User-Agent: curl/7.64.1 — Заголовок с информацией о клиенте, программе, запущенной у пользователя.
> Accept: */* — Заголовок с типами контента, которые клиент может корректно обработать.
> — После этой пустой строки могло быть тело запроса, но его редко используют в случае обработки данных методом GET.

Третья часть вывода — полное HTML-сообщение ответа веб-сервера со стартовой строкой, заголовками и телом, в котором передаётся HTML-код страницы:

< HTTP/1. 1 200 OK — Стартовая строка с версией протокола, кодом и статусом ответа сервера.
< Age: 258083 — Заголовок с временем жизни контента в кэше (в секундах).
< Cache-Control: max-age=604800 — Заголовок для определения времени (в секундах) и типа кэширования на сервере.
< Content-Type: text/html; charset=UTF-8 — Заголовок с типом контента и кодировкой.
< Date:Thu, 22 Jul 2021 15:42:57 GMT — Заголовок с датой и временем отправки сообщения.
< Etag: "3147526947+ident" — Заголовок с версией контента.
< Expires:Thu, 29 Jul 2021 15:42:57 GMT — Заголовок с датой и временем, после которых контент считается устаревшим.
< Last-Modified:Thu, 17 Oct 2019 07:18:26 GMT — Заголовок с датой и временем последнего изменения контента.
< Server:ECS (dcb/7F17) — Заголовок с именем веб-сервера. В нашем случае Elastic Cloud Server.
< Vary:Accept-Encoding — Заголовок, который отвечает за выбор стратегии кэширования и сжатия.
< X-Cache:HIT — Заголовок означает, что контент расположен на CDN (Content Delivery Network), а не на одном сервере.
< Content-Length: 1256 — Заголовок с информацией о длине контента в символах.
< — После этой пустой строки идёт тело ответа сервера, в нашем случае HTML-код страницы

Вы можете узнать больше о домене с помощью разных сервисов, например, с помощью domain.glass.

Эволюция HTTP — HTTP

HTTP (протокол передачи гипертекста) является базовым протоколом Всемирной паутины. Разработанный Тимом Бернерсом-Ли и его командой в период с 1989 по 1991 год, HTTP претерпел множество изменений, которые помогли сохранить его простоту и придать гибкость. Продолжайте читать, чтобы узнать, как HTTP превратился из протокола, предназначенного для обмена файлами в полудоверенной лабораторной среде, в современный интернет-лабиринт, который передает изображения и видео в высоком разрешении и 3D.

В 1989 году, работая в CERN, Тим Бернерс-Ли написал предложение о создании гипертекстовой системы через Интернет. Первоначально называвшийся Mesh , позже он был переименован в World Wide Web во время его внедрения в 1990 году. Построенный на основе существующих протоколов TCP и IP, он состоял из 4 строительных блоков:

Текстовый формат для представления гипертекстовых документов, язык гипертекстовой разметки (HTML).
Простой протокол для обмена этими документами, Протокол передачи гипертекста (HTTP).
Клиент для отображения (и редактирования) этих документов, первый веб-браузер под названием WorldWideWeb .
Сервер для предоставления доступа к документу, ранняя версия httpd .

Эти четыре строительных блока были завершены к концу 1990 года, и к началу 1991 года первые серверы работали за пределами ЦЕРН. 6 августа 1991 года Тим Бернерс-Ли опубликовал в общедоступной группе новостей alt. hypertext . Теперь это считается официальным запуском всемирной паутины как публичного проекта.

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

Первоначальная версия HTTP не имела номера версии; позже он был назван 0.9, чтобы отличить его от более поздних версий. HTTP/0.9 был предельно прост: запросы состояли из одной строки и начинались с единственно возможного метода GET , за которым следовал путь к ресурсу. Полный URL-адрес не был включен, так как протокол, сервер и порт не были необходимы после подключения к серверу.

 ПОЛУЧИТЬ /mypage.html

Ответ тоже был чрезвычайно прост: он состоял только из самого файла.

 
  Очень простая HTML-страница

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

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

Информация о версии была отправлена в каждом запросе ( HTTP/1.0 был добавлен к строке GET ).
В начале ответа также была отправлена строка кода состояния. Это позволяло самому браузеру распознавать успех или неудачу запроса и соответствующим образом адаптировать свое поведение. Например, обновление или использование своего локального кеша определенным образом.
Концепция заголовков HTTP была введена как для запросов, так и для ответов. Можно было передавать метаданные, и протокол стал чрезвычайно гибким и расширяемым.
Благодаря заголовку Content-Type можно было передавать документы, отличные от обычных HTML-файлов.

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

 GET /mypage.html HTTP/1.0
Агент пользователя: NCSA_Mosaic/2.0 (Windows 3.1)
200 ОК
Дата: вторник, 15 ноября 1994 г. , 08:12:31 по Гринвичу.
Сервер: CERN/3.0 libwww/2.17
Тип содержимого: текст/html

Страница с изображением

Затем последовало второе подключение и запрос на получение изображения (с соответствующим ответом):

 ПОЛУЧИТЬ /myimage.gif HTTP/1.0
Агент пользователя: NCSA_Mosaic/2.0 (Windows 3.1)
200 ОК
Дата: вторник, 15 ноября 1994 г., 08:12:32 по Гринвичу.
Сервер: CERN/3.0 libwww/2.17
Тип содержимого: текст/gif
(содержание изображения)

В период с 1991 по 1995 год они были представлены на пробной основе. Сервер и браузер добавят функцию и посмотрят, будет ли она востребована. Проблемы совместимости были обычным явлением. В целях решения этих проблем 19 ноября был опубликован информационный документ, описывающий общие практики.96. Он был известен как RFC 1945 и определял HTTP/1.0.

Тем временем велась надлежащая стандартизация. Это происходило параллельно с разнообразными реализациями HTTP/1.0. Первая стандартизированная версия HTTP, HTTP/1. 1, была опубликована в начале 1997 года, всего через несколько месяцев после HTTP/1.0.

HTTP/1.1 прояснил неясности и внес многочисленные улучшения:

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

Типичный поток запросов через одно соединение выглядел так:

 GET /en-US/docs/Glossary/Simple_header HTTP/1. 1
Хост: developer.mozilla.org
Агент пользователя: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Принять: текст/html, приложение/xhtml+xml, приложение/xml; q = 0,9, */*; q = 0,8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Реферер: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 ОК
Соединение: Keep-Alive
Кодировка содержимого: gzip
Тип содержимого: текст/html; кодировка = utf-8
Дата: среда, 20 июля 2016 г., 10:55:30 по Гринвичу
Метка: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: таймаут=5, макс=1000
Последнее изменение: Вт, 19 июля 2016 г., 00:59:33 GMT
Сервер: Апач
Передача-кодирование: по частям
Варьировать: Cookie, Accept-Encoding
(содержание)
ПОЛУЧИТЬ /static/img/header-background.png HTTP/1.1
Хост: developer.mozilla.org
Агент пользователя: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Принимать: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Реферер: https://developer. mozilla.org/en-US/docs/Glossary/Simple_header
200 ОК
Возраст: 9578461
Cache-Control: public, max-age=315360000
Соединение: Keep-alive
Длина контента: 3077
Тип содержимого: изображение/png
Дата: Чт, 31 марта 2016 г., 13:34:46 по Гринвичу
Последнее изменение: ср, 21 октября 2015 г., 18:27:50 GMT
Сервер: Апач
(содержание изображения 3077 байт)

HTTP/1.1 был впервые опубликован как RFC 2068 в январе 1997 года.

Расширяемость HTTP упростила создание новых заголовков и методов. Несмотря на то, что протокол HTTP/1.1 был улучшен в течение двух редакций, RFC 2616, опубликованных в июне 1999 г., и RFC 7230-RFC 7235, опубликованных в июне 2014 г. до выпуска HTTP/2, он оставался чрезвычайно стабильным в течение более 15 лет.

Использование HTTP для защищенной передачи

Наибольшее изменение в HTTP было сделано в конце 1994 года. Вместо отправки HTTP через базовый стек TCP/IP компания Netscape Communications, занимающаяся компьютерными услугами, создала дополнительный уровень зашифрованной передачи поверх это: SSL. SSL 1.0 никогда не публиковался, но SSL 2.0 и его преемник SSL 3.0 позволяли создавать веб-сайты электронной коммерции. Для этого они зашифровали и гарантировали подлинность сообщений, которыми обмениваются сервер и клиент. В конечном итоге SSL был стандартизирован и стал TLS.

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

Использование HTTP для сложных приложений

Тим Бернерс-Ли изначально не рассматривал HTTP как средство только для чтения. Он хотел создать сеть, в которой люди могли бы удаленно добавлять и перемещать документы — своего рода распределенную файловую систему. Примерно в 1996 году HTTP был расширен, чтобы разрешить авторизацию, и был создан стандарт под названием WebDAV. Он расширился за счет включения специальных приложений, таких как CardDAV для обработки записей адресной книги и CalDAV для работы с календарями. Но у всех этих расширений *DAV был недостаток: их можно было использовать только тогда, когда они были реализованы серверами.

В 2000 году был разработан новый шаблон для использования HTTP: передача репрезентативного состояния (или REST). API не был основан на новых методах HTTP, а вместо этого полагался на доступ к определенным URI с помощью базовых методов HTTP/1.1. Это позволило любому веб-приложению позволить API извлекать и изменять свои данные без необходимости обновлять браузеры или серверы. Вся необходимая информация была встроена в файлы, которые веб-сайты обслуживали по стандарту HTTP/1.1. Недостаток модели REST заключался в том, что каждый веб-сайт определял свой собственный нестандартный RESTful API и полностью контролировал его. Это отличалось от расширений *DAV, где клиенты и серверы были совместимы. RESTful API стали очень распространены в 2010-х годах.

С 2005 года для веб-страниц стало доступно больше API. Некоторые из этих API-интерфейсов создают расширения протокола HTTP для определенных целей:

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

Ослабление модели безопасности сети

HTTP не зависит от модели безопасности сети, известной как политика того же происхождения. Фактически, текущая модель веб-безопасности была разработана после создания HTTP! С годами оказалось полезным снять некоторые ограничения этой политики при определенных ограничениях. Сервер передавал клиенту, сколько и когда снимать такие ограничения, используя новый набор заголовков HTTP. Они были определены в таких спецификациях, как совместное использование ресурсов между источниками (CORS) и политика безопасности контента (CSP).

В дополнение к этим большим расширениям было добавлено много других заголовков, иногда только экспериментально. Примечательными заголовками являются заголовок Do Not Track ( DNT ) для управления конфиденциальностью, X-Frame-Options и Upgrade-Insecure-Requests , но существуют и многие другие.

С годами веб-страницы стали более сложными. Некоторые из них были даже самостоятельными приложениями. Было показано больше визуальных медиа, а также увеличился объем и размер сценариев, добавляющих интерактивность. Гораздо больше данных было передано через значительно большее количество HTTP-запросов, и это создало больше сложности и накладных расходов для соединений HTTP/1.1. Чтобы учесть это, в начале 2010-х Google внедрил экспериментальный протокол SPDY. Этот альтернативный способ обмена данными между клиентом и сервером вызвал интерес у разработчиков, работающих как с браузерами, так и с серверами. SPDY определил увеличение скорости отклика и решил проблему дублирования передачи данных, послужив основой для протокола HTTP/2.

Протокол HTTP/2 несколько отличается от HTTP/1.1:

Это двоичный, а не текстовый протокол. Его нельзя прочитать и создать вручную. Несмотря на это препятствие, он позволяет реализовать улучшенные методы оптимизации.
Это мультиплексный протокол. Параллельные запросы могут выполняться по одному и тому же соединению, что устраняет ограничения протокола HTTP/1.x.
Сжимает заголовки. Поскольку они часто похожи в наборе запросов, это устраняет дублирование и накладные расходы на передаваемые данные.
Позволяет серверу заполнять данные в клиентском кеше с помощью механизма, называемого серверной проталкиванием.

Официально стандартизированный в мае 2015 года протокол HTTP/2 оказался невероятно успешным. К маю 2022 года его использовали 46,4% всех веб-сайтов (см. статистику). Веб-сайты с высокой посещаемостью продемонстрировали наиболее быстрое внедрение в попытке сэкономить накладные расходы на передачу данных и последующие бюджеты.

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

HTTP не переставал развиваться с момента выпуска HTTP/2. Как и в случае с HTTP/1.x, расширяемость HTTP по-прежнему используется для добавления новых функций. В частности, можно привести новые расширения протокола HTTP, появившиеся в 2016 году:

Поддержка Alt-Svc позволила разъединить идентификацию и местоположение данного ресурса. Это означало более умный механизм кэширования CDN.
Введение Client-Hints позволило браузеру или клиенту заблаговременно передавать информацию о своих требованиях и аппаратных ограничениях на сервер.
Введение связанных с безопасностью префиксов в заголовок Cookie помогло гарантировать невозможность изменения безопасных файлов cookie.

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

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

Следующая основная версия HTTP, HTTP/3, будет использовать QUIC вместо TCP/TLS для части транспортного уровня.

См. ошибку 1158011, чтобы узнать о статусе реализации в Firefox.

Последнее изменение: 14 сентября 2022 г. , участниками MDN

Протокол Open Graph

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

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

Чтобы превратить ваши веб-страницы в графические объекты, вам необходимо добавить основные метаданные в твоя страница. Мы основывали первоначальную версию протокола на RDFa, что означает, что вы поместите дополнительные тегов в вашей веб-страницы. Четыре обязательных свойства для каждой страницы:

og:title — Название вашего объекта, как оно должно отображаться на графике, например, «Скала».
og:type — Тип вашего объекта, например, «video.movie». В зависимости от тип, который вы укажете, также могут потребоваться другие свойства.
og:image — URL-адрес изображения, который должен представлять ваш объект в график.
og:url — Канонический URL-адрес вашего объекта, который будет использоваться в качестве его постоянный идентификатор в графике, например, «https://www.imdb.com/title/tt0117500/».

В качестве примера ниже приведена разметка протокола Open Graph для The Rock on IMDB:

 
<голова>
Скала (1996)

 movie" />


...

...

Дополнительные метаданные

Следующие свойства являются необязательными для любого объекта и обычно рекомендуется:

og:audio — URL-адрес аудиофайла, сопровождающего этот объект.
og:description — Описание вашего объекта в одном-двух предложениях.
og:determiner — Слово, которое стоит перед заголовком этого объекта в предложении. Перечисление (a, an, the, «», auto). Если авто выбран, потребитель ваших данных должен выбрать между «а» или «ан». По умолчанию «» (пусто).
og:locale — локаль, в которой размечены эти теги. Формата language_TERRITORY . По умолчанию en_US .
og:locale:alternate — Массив других локалей на этой странице доступен в.
og:site_name — Если ваш объект является частью более крупного веб-сайта, имя которого должны отображаться для всего сайта. например, «IMDb».
og:video — URL-адрес видеофайла, дополняющего этот объект.

Например (разрыв строки исключительно для отображения):

Схема RDF (в Turtle) можно найти на ogp.me/ns.

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

Свойство og:image имеет несколько необязательных структурированных свойств:

og:image:url — идентично og:image .
og:image:secure_url — Альтернативный URL для использования, если веб-страница требует HTTPS.
og:image:type — Тип MIME для этого изображения.
og:image:width — Количество пикселей в ширину.
og:image:height — Количество пикселей в высоту.
og:image:alt — Описание того, что находится на изображении (не подпись). Если на странице указан og:image, он должен указать og:image:alt .

Пример полного изображения:

 
 example.com/ogp.jpg" />

ог:видео 9Тег 0038 имеет те же теги, что и og:image . Вот пример:

Тег og:audio имеет только первые 3 доступных свойства (поскольку размер не имеет значения для звука):

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

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

Например:

означает, что на этой странице 3 изображения, первое изображение 300x300 , среднее один имеет неуказанные размеры, а последний имеет высоту 1000 пикселей.

Чтобы ваш объект был представлен на графике, вам необходимо указать его тип. Это делается с помощью свойства og:type :

Когда сообщество согласовывает схему для типа, он добавляется в список глобальных типов. Все остальные объекты в системе типов КЮРИ формы

Глобальные типы сгруппированы по вертикалям. Каждая вертикаль имеет свою собственное пространство имен. Значения og:type для пространства имен всегда имеют префикс пространство имен, а затем точку. Это делается для того, чтобы избежать путаницы с определяемыми пользователем типами в пространстве имен, которые всегда иметь двоеточие в них.

`Музыка`

URI пространства имен: https://ogp.me/ns/music#

og:type values:

music. song

music:duration - integer >=1 - Продолжительность песни в секундах.
music:album - массив music.album - Альбом, из которого эта песня.
музыка:альбом:диск - целое число >=1 - На каком диске альбома эта песня.
музыка:альбом:дорожка - целое число >=1 - Какой трек это песня.
музыка:музыкант - массив профилей - Музыкант, написавший эту песню.

music.album

music:song - music.song - Песня из этого альбома.
музыка:песня:диск - целое число >=1 - То же, что и музыка:альбом:диск , но наоборот.
музыка:песня:дорожка - целое число >=1 - То же, что и music:album:track , но наоборот.
музыка:музыкант - профиль - Музыкант, написавший эту песню.
музыка: выпуск_дата - дата и время - Дата выхода альбома.

music.playlist

music:song - Идентичен музыкальному альбому
музыка:песня:диск
музыка:песня:дорожка
music:creator - profile - Создатель этого плейлиста.

music.radio_station

music:creator - profile - Создатель этой станции.

`Видео`

URI пространства имен: https://ogp.me/ns/video#

og:type значения:

video.movie

video:actor - массив профилей - Актеры в фильме.
video:actor:role - string - Роль, которую они сыграли.
видео: директор - массив профилей - Режиссеры фильма.
видео: писатель - массив профилей - Сценаристы фильма.
видео:длительность - целое число >=1 - Продолжительность фильма в секундах.
видео:release_date - дата и время - Дата выхода фильма.
видео: тег - массив строк - Отметьте слова, связанные с этим фильмом.

video.episode

video:actor - Идентичен video.movie
видео:актер:роль
видео:директор
видео:писатель
видео: продолжительность
видео: выпуск_дата
видео:тег
видео: сериал - video.tv_show - К какому сериалу относится этот эпизод.

video.tv_show

Многосерийное телешоу. Метаданные идентичны video.movie.

video.other

Видео, не принадлежащее ни к одной другой категории. Метаданные идентичны video.movie.

`Без вертикали`

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

og:type значения:

article — URI пространства имен: https://ogp.me/ns/article#

article:published_time — datetime — Когда статья была впервые опубликована.
статья:modified_time - дата и время - Когда статья была изменена в последний раз.
статья:expiration_time - дата и время - Когда статья устарела после.
статья: автор - массив профилей - Авторы статьи.
article:section - string - Высокоуровневое имя раздела. Например. Технология
статья:тег - массив строк - Отметьте слова, связанные с этой статьей.

книга — URI пространства имен: https://ogp.me/ns/book#

книга:автор - массив профилей - Кто написал эту книгу.
книга: ISBN - строка - ISBN
book:release_date - datetime - Дата выпуска книги.
book:tag - массив строк - Отметьте слова, связанные с этой книгой.

профиль — URI пространства имен: https://ogp.me/ns/profile#

профиль:first_name — строка — имя, обычно данное человеку родителем или выбранное им самим.
profile:last_name - string - Имя, унаследованное от семьи или брака и под которым обычно известен человек.
profile:username - строка - короткая уникальная строка для их идентификации.
profile:gender - enum(мужской, женский) - Их пол.

веб-сайт - URI пространства имен: https://ogp.me/ns/website#

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

Следующие типы используются при определении атрибутов в протоколе Open Graph.

Тип	Описание	Литералы
Логический	Логическое значение представляет значение true или false	правда, ложь, 1, 0
ДатаВремя	DateTime представляет временное значение, состоящее из даты (год, месяц, день) и необязательный компонент времени (часы, минуты)	ИСО 8601
перечисление	Тип, состоящий из ограниченного набора константных строковых значений (члены перечисления).	Строковое значение, входящее в перечисление
Поплавок	64-битное число с плавающей запятой со знаком	Все литералы, соответствующие следующим форматам: 1,234 -1,234 1.2e3 -1.2e3 7E-10
Целое число	32-битное целое число со знаком. Во многих языках целые числа более 32 бит становятся плавает, поэтому мы ограничиваем протокол Open Graph для удобства использования на нескольких языках.	Все литералы, соответствующие следующим форматам: 1234 -123
Строка	Последовательность символов Unicode	Все литералы, состоящие из символов Unicode без escape-символов
URL-адрес	Последовательность символов Unicode, идентифицирующая интернет-ресурс.	Все действительные URL-адреса, использующие протоколы https:// или https://

Вы можете обсудить протокол Open Graph в группе в фейсбуке или на список рассылки разработчиков. В настоящее время он используется Facebook (см. их документацию), Google (см. их документацию) и микси. Его публикуют IMDb, Microsoft, NHL, Posterous, Rotten Tomatoes, TIME, Yelp и многие другие.

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

Отладчик объектов Facebook — Официальный парсер и отладчик Facebook
Инструмент тестирования Google Rich Snippets — поддержка протокола Open Graph в определенных вертикалях и поисковых системах.
PHP Validator and Markup Generator — средство проверки ввода OGP 2011 и генератор разметки в объектах PHP5
PHP Потребитель - небольшая библиотека для доступа к данным Open Graph Protocol в PHP
OpenGraphNode в PHP — простой парсер для PHP
Пиопенграф — библиотека, написанная на Python для разбора протокола Open Graph информация с веб-сайтов
Рубиновый OpenGraph - Ruby Gem, который анализирует веб-страницы и извлекает разметку протокола Open Graph

. OpenGraph для Java —
небольшой класс Java, используемый для представления протокола Open Graph
 RDF::RDFa::Парсер -
Парсер Perl RDFa, который понимает протокол Open Graph
 Плагин WordPress -
Официальный плагин Facebook для WordPress, который добавляет метаданные Open Graph на сайты на базе WordPress.
 Альтернативный плагин WordPress OGP -
Простой легкий плагин WordPress, который добавляет метаданные Open Graph на сайты на базе WordPress.

`ДОПОЛНИТЕЛЬНЫЙ ПРОТОКОЛ К АМЕРИКАНСКОЙ КОНВЕНЦИИ О ПРАВАХ ЧЕЛОВЕКА В ОБЛАСТИ ЭКОНОМИЧЕСКИХ, СОЦИАЛЬНЫХ И КУЛЬТУРНЫХ ПРАВ "ПРОТОКОЛ САН-САЛЬВАДОР"`

   ДОПОЛНИТЕЛЬНЫЙ ПРОТОКОЛ К АМЕРИКАНСКОМУ
 КОНВЕНЦИЯ О ПРАВАХ ЧЕЛОВЕКА В ОБЛАСТИ ЭКОНОМИЧЕСКИХ, СОЦИАЛЬНЫХ И КУЛЬТУРНЫХ ПРАВ
 "ПРОТОКОЛ САН-САЛЬВАДОРА"
  Преамбула 
 Государства-участники американского
 Конвенция о правах человека «Пакт Сан-Хос, Коста-Рика»,
 подтверждая свое намерение консолидировать
 в этом полушарии в рамках демократических институтов система личных
 свобода и социальная справедливость, основанные на уважении основных прав человека;
 признавая, что основные права
 человека не вытекают из того, что он является гражданином определенного государства, а основываются на
 атрибуты человеческой личности, по этой причине они заслуживают международной защиты в
 форме конвенции, усиливающей или дополняющей охрану, обеспечиваемую
 внутреннее право американских штатов;
 Учитывая близкие отношения, которые
 существует между экономическими, социальными и культурными правами, а также гражданскими и политическими правами, в
 что различные категории прав составляют неделимое целое, основанное на
 признание достоинства человеческой личности, поэтому и то, и другое требует постоянного
 защиты и поощрения, если они должны быть полностью реализованы, и нарушение некоторых
 права в пользу реализации других никогда не могут быть оправданы;
 Признание преимуществ, вытекающих из
 поощрение и развитие сотрудничества между государствами и международных отношений;
 Напоминая, что в соответствии с
 Всеобщая декларация прав человека и Американская конвенция о правах человека,
 идеал свободных людей, наслаждающихся свободой от страха и нужды, может быть достигнут только в том случае, если
 создаются условия, при которых каждый может пользоваться своими экономическими, социальными и культурными правами
 а также его гражданские и политические права;
 Принимая во внимание, что, несмотря на принципиальную
 экономические, социальные и культурные права были признаны в более ранних международных
 инструменты как мирового, так и регионального масштаба, важно, чтобы эти права
 подтверждена, развита, усовершенствована и защищена, чтобы закрепиться в Америке, на
 основе полного уважения прав личности, демократической представительной формы
 правительства, а также право его народов на развитие, самоопределение и
 свободное распоряжение своим богатством и природными ресурсами; и
 Учитывая, что Американская конвенция
 о правах человека предусматривает, что проекты дополнительных протоколов к этой Конвенции могут
 представлен на рассмотрение государств-участников, собравшихся вместе по случаю
 Генеральная ассамблея Организации американских государств, с целью постепенного
 включение в систему их защиты иных прав и свобод, согласились
 после следующего Дополнительного протокола к Американской конвенции о правах человека
 «Протокол Сан-Сальвадора:»
   Статья 1
 Обязательство принять меры
 Государства-участники настоящего Дополнительного
 Протокол к Американской конвенции о правах человека обязуется принять необходимые
 меры как внутри страны, так и в рамках международного сотрудничества, особенно экономического и
 технических, насколько это позволяют имеющиеся у них ресурсы, и принимая во внимание
 степень их развития, с целью достижения постепенно и в соответствии с
 их внутреннего законодательства, полное соблюдение прав, признанных в настоящем
 Протокол.
  Артикул 2 
 Обязательство по принятию внутреннего законодательства
 Если осуществление прав установлено
 в настоящем Протоколе еще не гарантируется законодательными или иными положениями,
 Государства-участники обязуются принимать в соответствии со своими конституционными процедурами и
 положения настоящего Протокола, такие законодательные или иные меры, которые могут быть необходимы
 для воплощения этих прав в жизнь.
  Артикул 3 
 Обязательство не допускать дискриминации
 Государства-участники настоящего Протокола
 обязуются гарантировать осуществление прав, изложенных в настоящем документе, без дискриминации
 любого рода по причинам, связанным с расой, цветом кожи, полом, языком, религией, политическими или
 другие мнения, национальное или социальное происхождение, экономическое положение, рождение или любые другие социальные
 условие.
   Статья 4
 Недопустимость ограничений
 Право, которое признано или находится в
 действие в государстве в силу его внутреннего законодательства или международных конвенций может
 не ограничиваться или ограничиваться под тем предлогом, что настоящий Протокол не признает
 право или признает его в меньшей степени.
   Статья 5
 Объем ограничений и ограничений
 Государства-участники могут установить
 ограничения и ограничения на пользование и осуществление прав, установленных
 здесь с помощью законов, обнародованных с целью сохранения общего благосостояния в
 демократическом обществе только в той мере, в какой они не противоречат цели и
 причину, лежащую в основе этих прав.
  Артикул 6 
 Право на труд
 1. Каждый имеет право на труд,
 что включает в себя возможность обеспечить средства для достойной и достойной жизни
 существование путем осуществления свободно избранной или принятой законной деятельности.
 2. Государства-участники обязуются принять
 меры, которые сделают право на труд в полной мере эффективным, особенно в отношении
 достижение полной занятости, профориентация, развитие технических и
 проекты профессионального обучения, в частности ориентированные на инвалидов. Штаты
 Стороны также обязуются осуществлять и укреплять программы, помогающие обеспечить надлежащее
 забота о семье, с тем чтобы женщины могли пользоваться реальной возможностью осуществлять свое право на труд.
   Статья 7
 Справедливый, равноправный и удовлетворительный
 Условия работы
 Государства-участники настоящего Протокола
 признать, что право на труд, о котором говорится в предыдущей статье, предполагает, что
 каждый пользуется этим правом на справедливых, равноправных и удовлетворительных условиях, которые
 Государства-участники обязуются гарантировать в своем внутреннем законодательстве, в частности,
 по отношению к:
 а. Вознаграждение, гарантирующее, как
 как минимум, всем работникам достойные и достойные условия жизни для них и их семей
 и справедливую и равную заработную плату за равный труд без каких-либо различий;
 б. Право каждого работника следовать своему
 призвание и посвятить себя деятельности, которая лучше всего соответствует его ожиданиям и
 сменить место работы в соответствии с применимым национальным законодательством;
 в. Право каждого работника на повышение
 или продвижение по карьерной лестнице, с этой целью принимается во внимание его
 квалификация, компетентность, добросовестность и трудовой стаж;
 д. Стабильность занятости при условии
 характер каждой отрасли и занятия и причины справедливого разделения. В случаях
 необоснованного увольнения, работник имеет право на компенсацию или восстановление на
 работу или любые другие льготы, предусмотренные национальным законодательством;
 е. Безопасность и гигиена труда;
 ф. Запрещение работы в ночное время или
 вредные для здоровья или опасные условия труда и вообще всякой работы, которая подвергает опасности
 здоровья, безопасности или нравственности для лиц моложе 18 лет. В отношении несовершеннолетних в соответствии с
 16 лет, рабочий день подчиняется положениям об обязательном
 образование и ни в коем случае работа не может служить препятствием для посещения школы или
 ограничение использования полученного образования;
 грамм. Разумное ограничение работы
 часов, как ежедневно, так и еженедельно. Дни должны быть короче в случае опасных или
 нездоровая работа или работа в ночное время;
 час Отдых, досуг и оплачиваемый отпуск
 а также вознаграждение за национальные праздники.
   Статья 8
 Права профсоюзов
 1. Государства-участники обеспечивают:
 а. Право рабочих на организацию торговли
 союзы и вступать в союз по своему выбору с целью защиты и продвижения
 их интересы. В качестве расширения этого права Государства-участники разрешают торговлю
 союзы для создания национальных федераций или конфедераций или для присоединения к тем
 уже существующих, а также создавать международные профсоюзные организации и
 присоединиться к тому, что по своему выбору. Государства-участники также разрешают профсоюзам,
 федерации и конфедерации свободно функционируют;
 б. Право на забастовку.
 2. Осуществление прав, изложенных
 выше, могут применяться только ограничения, установленные законом, при условии, что такие
 ограничения характерны для демократического общества и необходимы для защиты
 общественного порядка или для защиты здоровья или нравственности населения или прав и свобод
 другие. Члены вооруженных сил и полиции и других основных государственных служб
 подлежат ограничениям и ограничениям, установленным законом.
 3. Никто не может быть принужден к принадлежности к
 профсоюз.
   Статья 9
 Право на социальное обеспечение
 1. Каждый имеет право на
 социальное обеспечение, защищающее его от последствий старости и инвалидности, которые
 мешает ему, физически или умственно, обеспечить средства для достойной и достойной
 существование. В случае смерти получателя пособия по социальному обеспечению
 применяется к его иждивенцам.
 2. В отношении лиц,
 по найму, право на социальное обеспечение должно охватывать как минимум медицинское обслуживание и пособие
 или пенсионное пособие в случае несчастных случаев на производстве или профессионального заболевания и, в
 случай женщин, оплачиваемый отпуск по беременности и родам до и после родов.
   Статья 10
 Право на здоровье
 1. Каждый имеет право на
 здоровье, понимаемое как наслаждение наивысшим уровнем физического, умственного и
 социальное самочувствие.
 2. Для обеспечения осуществления
 право на здоровье, государства-участники соглашаются признать здоровье общественным благом и,
 в частности, принять следующие меры для обеспечения этого права:
 а. Первичная медико-санитарная помощь, то есть основная
 медицинское обслуживание, доступное для всех людей и семей в сообществе;
 б. Расширение пользы для здоровья
 услуги всем лицам, находящимся под юрисдикцией государства;
 в. Универсальная иммунизация против
 основные инфекционные заболевания;
 д. Профилактика и лечение эндемичных,
 профессиональные и другие заболевания;
 е. Просвещение населения на
 профилактика и лечение проблем со здоровьем, и
 ф. Удовлетворение потребности в здоровье населения
 группы самого высокого риска и тех, чья бедность делает их наиболее уязвимыми.
   Статья 11
 Право на здоровую окружающую среду
 1. Каждый имеет право на
 жить в здоровой окружающей среде и иметь доступ к основным общественным услугам.
 2. Государства-участники содействуют
 защита, сохранение и улучшение
 Окружающая среда.
   Статья 12
 Право на питание
 1. Каждый имеет право на адекватное
 питание, гарантирующее возможность наслаждаться высочайшим уровнем физической,
 эмоциональное и интеллектуальное развитие.
 2. В целях содействия осуществлению
 этого права и искоренить недоедание, государства-участники обязуются совершенствовать методы
 производство, поставку и распределение продуктов питания, и с этой целью соглашаются содействовать более широкому
 международное сотрудничество в поддержку соответствующей национальной политики.
  Артикул 13 
 Право на образование
 1. Каждый имеет право на
 образование.
 2. Государства-участники настоящего Протокола
 согласны с тем, что образование должно быть направлено на всестороннее развитие человека
 личности и человеческого достоинства и должны укреплять уважение к правам человека, идеологическим
 плюрализм, основные свободы, справедливость и мир. Они также согласны с тем, что образование
 должна позволить каждому эффективно участвовать в демократическом и плюралистическом
 общества и добиться достойного существования и должны способствовать взаимопониманию, терпимости и
 дружбу между всеми нациями и всеми расовыми, этническими или религиозными группами и поощрять
 деятельность по поддержанию мира.
 3. Государства-участники настоящего Протокола
 признать, что для полного осуществления права на образование:
 а. Начальное образование должно быть обязательным
 и доступным для всех бесплатно;
 б. Среднее образование в его различии
 формы, в том числе среднее техническое и профессиональное образование, должны быть общепринятыми.
 быть доступным для всех любыми соответствующими средствами, и в частности,
 постепенное введение бесплатного образования;
 в. Высшее образование должно быть одинаковым
 доступным для всех, на основе индивидуальных способностей, всеми соответствующими средствами и в
 в частности, путем постепенного введения бесплатного образования;
 д. Базовое образование следует поощрять или
 максимально усилены для тех лиц, которые не получили или не завершили
 полный цикл начального обучения;
 е. Программы специального образования должны быть
 создан для инвалидов, с тем чтобы обеспечить специальные инструкции и обучение для
 лица с физическими недостатками или умственными недостатками.
 4. В соответствии с внутренним
 законодательстве государств-участников, родители должны иметь право выбора вида
 образование, которое они должны давать своим детям, при условии, что оно соответствует принципам, установленным
 выше.
 5. Ничто в настоящем Протоколе не должно
 интерпретируется как ограничение свободы физических и юридических лиц создавать и
 непосредственные образовательные учреждения в соответствии с внутренним законодательством государств
 Стороны.
   Статья 14
 Право на блага культуры
 1. Государства-участники настоящего Протокола
 признавать право каждого:
 а. Принимать участие в культурных и
 художественная жизнь общества;
 б. Чтобы пользоваться преимуществами научных и
 технологический прогресс;
 в. Чтобы воспользоваться защитой морального
 и материальные интересы, вытекающие из любого научного, литературного или художественного произведения
 автором которого он является.
 2. Шаги, которые необходимо предпринять Штатам
 Стороны настоящего Протокола для обеспечения полного осуществления этого права включают те
 необходимых для сохранения, развития и распространения науки, культуры и искусства.
 3. Государства-участники настоящего Протокола
 обязуются уважать свободу, необходимую для научных исследований и творчества
 Мероприятия.
 4. Государства-участники настоящего Протокола
 признать выгоды, которые можно извлечь из поощрения и развития
 международное сотрудничество и связи в области науки, искусства и культуры, а также
 соответственно соглашаются укреплять международное сотрудничество в этих областях.
   Статья 15
 Право на образование и защиту
 семей
 1. Семья – это естественная и
 основным элементом общества и должен находиться под защитой государства, которое должно заботиться о
 улучшение своего духовного и материального положения.
 2. Каждый имеет право образовать
 семьи, которая осуществляется в соответствии с положениями соответствующего
 отечественное законодательство.
 3. Государства-участники настоящим обязуются
 предоставить надлежащую защиту семейной ячейке и, в частности:
 а. Обеспечить особую заботу и помощь
 матерям в течение разумного периода до и после родов;
 б. Чтобы гарантировать адекватное питание для
 дети на этапе вскармливания и в годы посещения школы;
 в. Принять специальные меры для
 защита подростков с целью обеспечения всестороннего развития их физических,
 интеллектуальные и моральные способности;
 д. Проведение специальных семейных программ
 обучения, чтобы помочь создать стабильную и позитивную среду, в которой дети будут
 получать и развивать ценности понимания, солидарности, уважения и ответственности.
   Статья 16
 Права детей
 Каждый ребенок, независимо от его происхождения,
 имеет право на защиту, которую его статус несовершеннолетнего требует от его семьи,
 общества и государства. Каждый ребенок имеет право расти под защитой и
 ответственность его родителей; за исключением исключительных обстоятельств, признанных в судебном порядке,
 ребенка младшего возраста не следует разлучать с матерью. Каждый ребенок имеет право на
 бесплатное и обязательное образование, по крайней мере, на начальном этапе, и продолжать
 обучение на высших ступенях системы образования.
   Статья 17
 Защита пожилых людей
 Каждый имеет право на особое
 защита в старости. С этой целью государства-участники соглашаются постепенно принимать
 необходимые шаги для реализации этого права и, в частности, для:
 а. Обеспечьте соответствующие условия, а также
 питания и специализированной медицинской помощи, для лиц преклонного возраста, нуждающихся в них и не способных
 обеспечить их для себя;
 б. Выполнять рабочие программы специально
 предназначен для того, чтобы дать пожилым людям возможность участвовать в продуктивной деятельности, подходящей для
 их способности и соответствуют их призванию или желаниям;
 в. Способствовать созданию соц.
 организаций, направленных на улучшение качества жизни пожилых людей.
   Статья 18
 Защита инвалидов
 Все, кого коснулось уменьшение
 его физические или умственные способности имеют право на особое внимание, направленное на
 помочь ему добиться максимально возможного развития его личности. Государства-участники
 согласиться принять такие меры, которые могут быть необходимы для этой цели и, в частности, на:
 а. Осуществлять программы, специально направленные
 в предоставлении инвалидам ресурсов и условий, необходимых для достижения этого
 цели, включая рабочие программы, соответствующие их возможностям и свободно принимаемые
 они или их законные представители, в зависимости от обстоятельств;
 б. Проводить специальную подготовку для
 семьям инвалидов, чтобы помочь им решить проблемы сосуществования и
 превращать их в активные агенты физического, умственного и эмоционального развития
 последний;
 в. Включить рассмотрение решений
 конкретным требованиям, вытекающим из потребностей этой группы, как приоритетной составляющей их
 планы развития города;
 д. Стимулировать создание соц.
 группы, в которых можно помочь инвалидам вести более полноценную жизнь.
   Статья 19
 Средства защиты
 1. В соответствии с положениями настоящего
 статью и соответствующие правила, которые должны быть сформулированы для этой цели Генеральным
 Ассамблея Организации американских государств, государств-участников настоящего Протокола
 обязуются представлять периодические отчеты о прогрессивных мерах, которые они предприняли для обеспечения
 должное уважение прав, изложенных в настоящем Протоколе.
 2. Все отчеты представляются
 Генеральному секретарю ОАГ, который передает их Межамериканскому экономическому и
 Социальный совет и Межамериканский совет по образованию, науке и культуре, с тем чтобы
 они могут рассматривать их в соответствии с положениями настоящей статьи. Секретарь
 General направляет копии таких отчетов в Межамериканскую комиссию по правам человека.
 Права.
 3. Генеральный секретарь
 Организация американских государств также передает специализированным организациям
 межамериканская система, членами которой являются государства-участники настоящего Протокола,
 копии или соответствующие части представленных отчетов, поскольку они касаются вопросов
 в компетенцию этих организаций, как это установлено их учредителями
 инструменты.
 4. Специализированные организации
 межамериканская система может представлять отчеты в Межамериканский экономический и социальный совет
 и Межамериканский совет по образованию, науке и культуре относительно соблюдения
 с положениями настоящего Протокола в своих сферах деятельности.
 5. Годовые отчеты, представляемые
 Генеральная ассамблея Межамериканского экономического и социального совета и Межамериканского
 Совет по образованию, науке и культуре должен содержать краткую информацию
 полученные от государств-участников настоящего Протокола и специализированных организаций
 относительно прогрессивных мер, принятых для обеспечения уважения прав
 признаются в самом Протоколе и в общих рекомендациях, которые они считают
 уместно в этом отношении.
 6. Любой случай, когда права
 установленные в пункте а) статьи 8 и в статье 13, нарушаются действием непосредственно
 присваиваемые государству-участнику настоящего Протокола, могут привести к возникновению в результате участия
 Межамериканской комиссии по правам человека и, когда это применимо, Межамериканской
 Суд по правам человека, к применению системы индивидуальных жалоб, регулируемой
 Статьи с 44 по 51 и с 61 по 69 Американской конвенции о правах человека.
 7. Без ущерба для положений
 предыдущего параграфа, Межамериканская комиссия по правам человека может сформулировать такие
 замечания и рекомендации, которые он сочтет уместными в отношении статуса
 экономические, социальные и культурные права, закрепленные в настоящем Протоколе, во всех или некоторых
 государства-участники, которые он может включить в свой ежегодный доклад Генеральной Ассамблее или
 в специальном отчете, в зависимости от того, что он считает более подходящим.
 8. Советы и Межамериканский
 Комиссии по правам человека при выполнении функций, возложенных на них настоящим
 статьи, учитывать прогрессивный характер соблюдения прав
 подлежат охране настоящим Протоколом.
   Статья 20
 Бронирование
 Государства-участники могут во время
 утверждения, подписания, ратификации или присоединения, делать оговорки к одному или нескольким конкретным
 положений настоящего Протокола при условии, что такие оговорки не являются несовместимыми с
 объект и цель Протокола.
   Статья 21
 Подписание, ратификация или присоединение
 Вступление в силу
 1. Настоящий Протокол остается открытым для
 подписание и ратификация или присоединение любого государства-участника к Американской конвенции о
 Права человека.
 2. Ратификация или присоединение к настоящему
 Протокол вступает в силу путем сдачи на хранение ратификационной грамоты или документа о присоединении
 Генеральный секретариат Организации американских государств.
 3. Протокол вступает в силу
 когда одиннадцать государств сдали на хранение свои соответствующие ратификационные грамоты или
 вступление.
 4. Генеральный секретарь уведомляет всех
 государства-члены Организации американских государств вступления Протокола в
 эффект.
   Статья 22
 Включение других прав и расширение
 признанных
 1. Любое государство-участник и
 Межамериканская комиссия по правам человека может представить на рассмотрение государств
 Стороны, собравшиеся по случаю Генеральной Ассамблеи, предложили поправки, включающие
 признание других прав или свобод или расширение или расширение прав или свобод
 признаются в настоящем Протоколе.
No related posts.