Http протокол передачи гипертекста

Преимущество http/2 для разработчиков

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

• Доменное
  шардирование. Раньше в http/1.1
  число открытых соединений было ограничено. Но можно было установить большое количество
  соединений за счет загрузки файлов сразу с нескольких поддоменов, чтобы
  ускорить работу. Такой подход был особенно актуальным для сайтов, куда
  загружено множество изображений. Теперь благодаря HTTP/2 нет нужды прибегать к домен-шардингу,
  потому что протокол дает возможность запросить неограниченное количество ресурсов.
  Тем более, что с новым протоколом доменное шардирование не только не повысит производительность,
  но и нагрузит сервер лишними соединениями.
• Объединение
  скриптов Java и CSS. Процедура заключается в том, чтобы из множества
  маленьких файлов создать один большой. Это конечно уменьшает число запросов, но
  пользователь, посетив страницу, загрузит абсолютно все CSS и JS файлы, даже те, которые ему не
  понадобятся. Соответственно объединение файлов съедает память. Еще одна
  трудность – все элементы нуждаются в одновременной чистке из кэша, так как
  недопустимо, чтобы дата окончания срока действия каждого из них разнилась. Если
  поменять даже одну строку в CSS,
  срок действия закончится у всех элементов одновременно. HTTP/2 позволяет не прибегать к объединению
  файлов, потому что он не затрачивает много ресурсов.
• Объединение
  картинок (спрайты). Тоже снижает количество запросов, но так как вес изображения
  увеличится, загружаться он будет дольше. Более того, для показа хотя бы одной
  картинки нужно загрузить весь спрайт. Вывод – применение спрайтов чревато занятием
  больших объемов памяти.
• Доменные
  имена без cookie. Подразумевает загрузку
  изображений, JS и CSS файлов с другого домена, где нет данных cookie.
• Перенос JavaScript, CSS, картинок в HTML-файл. Аналогично уменьшает количество соединений, но
  страница не отобразится до полной загрузки всего файла.

3.4 Кодовые таблицы (character sets).

HTTP использует то же самое определение термина «кодовая таблица»,
которое описано для MIME:

Термин «кодовая таблица» используется в данном документе, чтобы
сослаться на метод, использующий одну или несколько таблиц для
преобразования последовательности октетов в последовательность
символов. Стоит отметить, что однозначное преобразование в
обратном направлении не требуется, и что не все символы могут
быть доступны в данной кодовой таблице, и что кодовая таблица
может обеспечивать более чем одну последовательность октетов для
представления специфических символов. Это определение допускает
различные виды кодирования символов, от простых однотабличных
отображений типа US-ASCII до сложных методов, переключающих
таблицы, наподобие тех, которые используют методики ISO 2022.
Однако определение, связанное с именем кодовой таблицы MIME
ДОЛЖНО полностью определять отображение, которое преобразует
октеты в символы. В частности использование внешней информации
профилирования для определения точного отображения не
разрешается.

Обратите внимание: Это использование термина «кодовая таблица»
обычно упоминается как «кодирование символов»

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

Полный набор лексем определен реестром кодовых таблиц
.

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

          charset = token

Хотя HTTP позволяет использовать в качестве значения charset
произвольную лексему, любая лексема, которая имеет предопределенное
значение в реестре кодовых таблиц IANA, ДОЛЖНА представлять набор
символов, определенный в данном реестре. Приложениям СЛЕДУЕТ
ограничить использование символьных наборов теми, которые
определены в реестре IANA.

HTTP-заголовки

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

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

Заголовки запросов

К числу наиболее важных HTTP-заголовков, которые можно включать в запросы, но нельзя включать в ответы, относятся:

Заголовок Accept

Это список MIME-типов, принимаемых клиентом, в формате тип/подтип. Элементы списка должны разделяться запятыми:

Accept: text/html, image/gif, */*

Элемент */* указывает, что все типы будут приняты и обработаны клиентом. Если тип запрошенного файла не может быть обработан клиентом, возвращается ошибка HTTP 406 «Not acceptable» (недопустимо).

Заголовок From

Указывает адрес электронной почты в Интернете учетной записи пользователя, под которой работает клиент, направивший запрос:

From: alexerohinzzz@gmail.com

Заголовок Referer

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

Referer: http://www.professorweb.ru

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

Представляет собой строку, идентифицирующую приложение-клиент (обычно браузер) и платформу, на которой оно выполняется. Общий формат имеет вид: программа/версия библиотека/версий, но это не неизменный формат:

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) 
   Chrome/24.0.1312.56 Safari/537.17

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

Заголовки ответов

В ответы могут включаться следующие заголовки:

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

Используется для указания типа данных, отправляемых получателю или, в случае метода HEAD, тип данных, который был бы отправлен в ответ на запрос GET:

Content-Type: text/html

Заголовок Expires

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

Expires: Fri, 19 Aug 2012 16:00:00 GMT

Заголовок Location

Определяет точное расположение другого ресурса, к которому может быть перенаправлен клиент. Если это значение представляет собой полный URL, сервер возвращает клиенту «redirect» для непосредственного извлечения указанного объекта:

Location: http://www.samplesite.com

Если ссылка на другой файл относится к серверу, должен указываться частичный URL.

Заголовок Server

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

Server: Microsoft-IIS/7.0

Общие заголовки

Несколько заголовков могут включаться как в запрос, так и в ответ, например:

Заголовок Date

Используется для установки даты и времени создания сообщения:

Date: Tue, 16 Aug 2012 18:12:31 GMT

Заголовок Connection

В НТТР/1.0 мы могли использовать в запросе заголовок Connection, указывая, что хотим сохранить соединение после отправки ответа. Теперь такое поведение принято по умолчанию, и в HTTP/1.1 можно использовать заголовок Connection, чтобы указать, что постоянное соединение не нужно:

Connection: close

Переходим на HTTPS

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

Шаг 1: Подготовка сайта

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

Чтобы избежать предупреждения, указанного выше, необходимо изменить все внутренние ссылки с абсолютных на относительные. Например, ссылку http://ssl.ru/testpage/ потребуется заменить на /testpage/. Также стоит внимательно проверить все ссылки на скрипты в коде страниц. 

Второй момент — проверка медиаконтента, в который входят изображения, видеоклипы, презентации и прочее. Необходимо посмотреть, какой на страницах сайта используется контент и по какому протоколу он запрашивается. Если используется HTTP, то рекомендуется загрузить все файлы на сервер и установить относительные ссылки. В противном случае указывайте только проверенные сайты: YouTube, Facebook, VK и так далее.

Теперь можно переходить к подключению SSL.

Шаг 2: Установка SSL-сертификата

Устанавливаем SSL:

Проверить подлинность сертификата можно на различных сервисах, например, Namecheap. Все просто: вводим домен с портом 443 и жмем «Check». При успешной проверке будет отображена надпись «It’s all good. We have not detected any issues».

После установки также рекомендуется убедиться, что сайт работает на обоих протоколах. Затем нужно сделать переадресацию с HTTP на HTTPS. Зачем это нужно, расскажем уже в следующем разделе.

Шаг 3: Настройка редиректа на HTTPS

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

Первый вариант:

RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} 

Второй вариант:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 

Третий вариант:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} 

Также мы можем сделать редирект с HTTP через административную панель CMS системы. В OpenCart для этого нужно открыть файл config.php и прописать в него следующее:

define('HTTPS_SERVER', 'https://yourdomain.com/');

В WordPress изменить wp-config.php:

define('FORCE_SSL_ADMIN', true);

Для получения подробной информации о редиректах на других CMS обратитесь к их документации.

Шаг 4: Настройка для поисковых систем

Если ваш сайт индексируется Google, Яндекс или другими поисковиками, то после перехода на HTTPS необходимо им об этом сообщить. В частности, нужно:

1. Изменить все теги «rel=canonical» в HTML-коде. Они должны указывать на ссылки с защищенным протоколом.
2. В файлы robots.txt и sitemap.xml необходимо добавить страницы с HTTPS.
3. Проверить корректность указанных данных в Яндекс.Метрика и Google Search Console.
4. Проверить отображение и доступность вашего сайта через поисковик.

Готово! На этом переход с HTTP на HTTPS завершен. Надеюсь, что у вас не возникло сложностей

Спасибо за внимание!

Определения поля заголовка

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

4.1. Заголовок WWW-Authenticate

Поле заголовка «WWW-Authenticate» указывает схему (ы) аутентификации и параметры, применимые к целевому ресурсу.

Сервер, генерирующий ответ 401 (неавторизованный), ДОЛЖЕН отправить поле заголовка WWW-Authenticate, содержащее, по крайней мере, один запрос. Сервер МОЖЕТ генерировать поле заголовка WWW-Authenticate в других ответных сообщениях, чтобы указать, что предоставление учетных данных (или других учетных данных) может повлиять на ответ.

Прокси-сервер, пересылающий ответ, НЕ ДОЛЖЕН изменять поля WWW-Authenticate в этом ответе.

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

Например:

Это поле заголовка содержит две проблемы; один для схемы «Newauth» со значением области «apps» и двумя дополнительными параметрами «type» и «title«, а другой для схемы «Basic» со значением области «simple«.

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

4.2. Заголовок Authorization

Поле заголовка «Authorization» позволяет агенту пользователя аутентифицироваться на сервере происхождения — обычно, но не обязательно, после получения ответа 401 (Несанкционированный). Его значение состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрашиваемого ресурса.

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

Прокси-сервер, пересылающий запрос, НЕ ДОЛЖЕН изменять любые поля Authorization в этом запросе. См. Раздел 3.2 для получения подробной информации и требований, касающихся обработки поля Authorization кешами HTTP.

4.3. Заголовок Proxy-Authenticate

Поле заголовка «Proxy-Authenticate» состоит как минимум из одного запроса, который указывает схему (ы) аутентификации и параметры, применимые к прокси для этого эффективного URI запроса ( ). Прокси-сервер ДОЛЖЕН отправлять хотя бы одно поле заголовка Proxy-Authenticate в каждом генерируемом им ответе 407 (Proxy Authentication Required).

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

Обратите внимание, что соображения синтаксического анализа для WWW-Authenticate применимы и к этому полю заголовка; см. для деталей

4.4. Заголовок Proxy-Authorization

Поле заголовка «Proxy-Authorization» позволяет клиенту идентифицировать себя (или своего пользователя) для прокси, который требует аутентификации. Его значение состоит из учетных данных, содержащих информацию аутентификации клиента для прокси и / или области запрашиваемого ресурса.

В отличие от авторизации, поле заголовка Proxy-Authorization применяется только к следующему входящему прокси, который потребовал аутентификацию с использованием поля Proxy-Authenticate. Когда в цепочке используется несколько прокси, поле заголовка Proxy-Authorization используется первым входящим прокси, который ожидал получить учетные данные. Прокси МОЖЕТ передавать учетные данные из запроса клиента следующему прокси, если это механизм, с помощью которого прокси совместно аутентифицируют данный запрос.

HTTP/3 идет

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

HTTP/2 Использование

На момент написания этой статьи HTTP/3 был интернет-проектом или идентификатором IETF , что означает, что в настоящее время рассматривается вопрос о готовящемся стандарте интернета, подготовленный Целевой группой по интернет-разработкам – международному органу по стандартизации интернета , отвечающему за определение и продвижение согласованных стандартов интернет-протокола, таких как TCP, IPv6 , VoIP, Интернет вещей и т. д.

Это открытый орган, который объединяет интернет-индустрию и способствует обсуждению направления Интернета.

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

Это означает, что HTTP/3 должен стать официальным стандартом после истечения срока действия проекта в конце этого года (июнь 2019 года).

Что такое индексация сайта?

Найти сайт в интернете можно тремя способами:

Поисковики (Яндекс, Гугл, Бинг и др.) получают ежедневно миллионы запросов и должны находить нужную пользователям информацию за доли секунды.

Они не могут по каждому запросу сканировать весь интернет, в котором миллиарды интернет-страниц — на это не хватит никаких ресурсов и по времени это очень долго.

Поэтому поисковые системы создают текстовые копии всех известных интернет-страниц. База этих копий называется index, а поиск и создание копий страниц — индексирование.

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

Структура протокола

Запрос

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

Request            = Request-Line	
                          *( generalheader	
                          | requestheader	
                          | entityheader )	
                          CRLF	
                          

Отклик

После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.

Response	= Status-Line	; Раздел 5.1
*( general-header	; Раздел 3.5
| response-header	; Раздел 5.2
| entity-header )	; Раздел 6.1
CRLF	
	; Раздел 6.2

Отправив HTTP-запрос серверу, клиент ожидает ответа. HTTP-ответ выглядит в целом аналогично запросу: статусная строка, список заголовков и тело ответа.

HTTP/1.1 200 OK
Server: nginx/0.5.35
Date: Tue, 22 Apr 2008 10:18:08 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
Last-Modified: Fri, 30 Nov 2007 12:46:53 GMT
ETag: ``27e74f-43-4750063d''
Accept-Ranges: bytes
Content-Length: 34

User-agent: *
Disallow: /people

Объект и соединение

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

Структура ресурса и объекта

Постоянное HTTP соединение имеет много преимуществ:

• При открытии и закрытии TCP соединений можно сэкономить время CPU и память, занимаемую управляющими блоками протокола TCP.
• HTTP запросы и отклики могут при установлении связи буферизоваться (pipelining), образуя очередь. Буферизация позволяет клиенту выполнять множественные запросы, не ожидая каждый раз отклика на запрос, используя одно соединение TCP более эффективно и с меньшими потерями времени.
• Перегрузка сети уменьшается за счет сокращения числа пакетов, сопряженных с открытием и закрытием TCP соединений, предоставляя достаточно времени для детектирования состояния перегрузки.
• HTTP может функционировать более эффективно, так как сообщения об ошибках могут доставляться без потери TCP связи.Клиенты, использующие будущие версии HTTP, могут испытывать новые возможности, взаимодействуя со старым сервером, они могут после неудачи попробовать старую семантику. HTTP реализациям следует пользоваться постоянными соединениями.

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются Менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Виртуальные атласы тоже используют HTTP.

Оптимизация

Оптимизация с помощью HTTP keep-alive

Протокол HTTP работает поверх протокола TCP («Transmission Control Protocol»). TCP — это надёжный протокол двусторонней передачи потока данных. TCP работает, пересылая пакеты данных от клиента к серверу и обратно. TCP-пакет состоит из заголовка и данных. В заголовке указаны, помимо прочего, IP-адреса клиента и сервера, номера TCP-портов, используемых на клиенте и сервере, и набор флагов. Для HTTP на сервере обычно используется стандартный TCP-порт номер 80.

TCP-соединение между клиентом и сервером устанавливается с помощью классического «TCP three-way handshake». Сначала клиент посылает серверу пакет с флагом SYN. В ответ сервер посылает пакет с флагами SYN+ACK. Наконец, клиент посылает ещё один пакет, с флагом ACK и с этой минуты соединение считается установленным, и клиент может посылать свои данные, в нашем случае — HTTP-запрос.
Понятно, что если десяток тысяч браузеров установит с сервером keep-alive соединение, то они достаточно быстро исчерпают его ресурсы. Поэтому во всех серверах есть конфигурируемый тайм-аут, по истечении которого keep-alive соединение разрывается, если на нём не было никакой активности.

Клиент может запросить разрыв соединения после ответа, передав в запросе заголовок Connection: close. Аналогично, сервер может сообщить в ответе, что не желает поддерживать keep-alive соединение, передав точно такой же заголовок: Connection: close. Вообще говоря, все эти расшаркивания с взаимным уведомлением, строго говоря, не налагают никаких обязанностей. И сервер, и клиент должны быть полностью готовы к тому, что соединение прервётся в любой момент времени по инициативе другой стороны без каких-либо уведомлений.

Для того, чтобы соблюсти целостность keep-alive соединения, сервер должен знать длину ответа. Самый простой способ — указать её в заголовке Content-Length. Если длина ответа не указана обработчиком, то сервер вынужден перед отправкой ответа установить заголовок Connection: close и закрыть соединение со своей стороны после отправки ответа.

Оптимизация с помощью компрессии

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

Способность принимать компрессированное содержимое клиент анонсирует серверу с помощью заголовка Accept-Encoding: gzip. Если сервер настроен на сжатие соответствующего контента, то он может добавить заголовок ответа Content-Encoding: gzip (не путать с Transfer-Encoding) и отправить клиенту сжатое содержимое.

Оптимизация с помощью HTTP-pipelining

Когда мы делаем серию запросов и ответов в рамках одного keep-alive соединения, важную роль в производительности играет время задержки (latency) между запросом и ответом. Задержка может быть вызвана как высокой задержкой на канале, так и большим временем обработки запросов на сервере. Перед посылкой очередного запроса мы должны дождаться завершения обработки следующего. Чтобы справиться с этой проблемой, может использоваться технология HTTP-pipelining.

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

Резюме¶

Протокол HTTP это:

• однонаправленный (запрос/ответ)
• текстовый протокол
• не хранит состояния
• работает на сетевом уровне только через TCP
• может передавать любые данные
• используется не только в браузерах
• обслуживает львиную долю Интернет трафика

Достоинства

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

Недостатки

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

• Отсутствие навигации. У протокола отсутствую средства навигации среди
  ресурсов сервера. Клиент не может, как в FTP запросить список доступных
  файлов. Протокол предполагает, что пользователю уже известен URI
  интересующего его ресурса.

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

  Карта сайта может использоваться как пользователем, так и
  роботами-пауками поисковых систем, уменьшая для них глубину
  просмотра—минимально необходимое количество переходов с главной страницы.
  Аналогичную функцию выполняют и файлы sitemap, но только для
  приложений. Данная проблема полностью решена в протоколе более высокго
  уровня WebDAV с помощью добавленного метода PROPFIND, который
  позволяет получить не только дерево каталогов, но и список параметров
  каждого ресурса.

• Отсутствие поддержки распределённости. Изначально протокол HTTP
  разрабатывался для решения типичных бытовых задач, где само по себе время
  обработки запроса должно занимать незначительное время или вовсе не
  приниматься в расчёт. Однако со временем стало очевидно, что при
  промышленном использовании с применением распределённых вычислений при
  высоких нагрузках на сервер протокол HTTP оказывается непригоден. В
  связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next
  Generation), но этот протокол до сих пор находится на стадии разработки.

HTTP-запросы

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

Клиент связывается с сервером в назначенном номере порта (по умолчанию равном 80) и запрашивает у сервера документ, задавая HTTP-команду, называемую методом, за которой следует адрес документа и номер версии HTTP. Клиент также отправляет серверу необязательную информацию в заголовках, чтобы сообщить серверу о своей конфигурации и приемлемых для него форматах документов. Информация заголовка дается в одной строке вместе с именем и значением заголовка. После заголовков клиент посылает пустую строку. Затем клиент отправляет дополнительные данные. Это могут быть данные формы, отправляемые на сервер методом POST, или файл, копируемый на сервер методом PUT.

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

GET /default.aspx HTTP/1.1

Теперь исследуем каждую из этих секций. Метод — это HTTP-команда, начинающая первую строку запроса клиента. Метод информирует сервер о цели запроса клиента. Для HTTP определены семь методов: GET, HEAD, POST, OPTIONS, PUT, DELETE и TRACE, но HTTP-серверы могут также реализовать методы расширения, не определенные протоколом HTTP. Заметим, что названия методов зависят от регистра клавиатуры, поэтому, например, слово get не будет распознано как допустимый метод.

Метод GET используется для запроса информации, расположение которой на сервере определяется заданным URI. Этот метод широко применяется браузерами, чтобы извлекать документы для просмотра. Результат запроса GET генерируется разными способами. Это может быть файл, доступный с сервера, вывод программы, вывод, полученный на устройстве, и т. д.

Когда клиент в своем запросе использует метод GET, сервер отправляет ответ, содержащий строку состояния, заголовки и метаданные. Если сервер не может обработать запрос из-за ошибки или отсутствия авторизации, он отправляет объяснение в текстовом виде, помещая его в ответе в секцию данных.

Секция тела о сути запроса GET всегда остается пустой. Запрошенный клиентом ресурс (файл или программа) идентифицируется по его полному пути на сервере. Любая дополнительная информация, например, значения из формы, которую клиенту нужно отправить серверу, присоединяется вслед за URI как строка запроса:

GET /default.aspx?name=Alex HTTP/1.1

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

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

В методе OPTIONS запрашивается информация о поддержке HTTP на Web-cepвeре. Метод OPTIONS может применяться с URL, чтобы извлечь информацию о конкретном документе или, с групповым символом *, чтобы получить информацию о возможностях сервера в целом. Информация возвращается в заголовках ответа.

3.11 Метки объектов (Entity Tags).

Метки объектов используются для сравнения двух или более объектов
от одного и того же запрошенного ресурса. HTTP/1.1 использует метки
объекта в полях заголовка ETag (),
If-Match (), If-None-Match
(), и If-Range
().
Определение того, как они используются и сравниваются в качестве
меток проверки кэша находится в . Метка объекта
состоит из непрозрачной цитируемой строки (opaque quoted string),
возможно предваренной индикатором слабости (weakness indicator).

         entity-tag =  opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

«Сильная метка объекта» («strong entity tag») может быть разделена
двумя объектами ресурса, только если они пооктетно эквивалентны.

«Слабая метка объекта» («weak entity tag»), обозначяемая префиксом
«W/», может быть разделена двумя объектами ресурса только если
объекты эквивалентны и могли бы заменять друг друга без
значительного изменения в семантике. Слабая метка объекта может
использоваться только для слабого сравнения.

Метка объекта ДОЛЖНА быть уникальна среди всех версий всех
объектов, связанных с конкретным ресурсом. Данное значение метки
объекта может использоваться для объектов, полученных запросами
различных URI без предположения эквивалентности этих объектов.