дизайнеры-верстальщики или как вас там есть?)

[Tour]

Гиперссылка (англ. hyperlink) в компьютерной терминологии — часть гипертекстового документа, ссылающаяся на другой элемент (команда, текст, заголовок, примечание, изображение) в самом документе, на другой объект (файл, директория, приложение), расположенный на локальном диске или в компьютерной сети, либо на элементы этого объекта.
Гиперссылка может быть добавлена к любому элементу гипертекстового документа и обычно выделяется графически. В HTML-документах текстовые ссылки по умолчанию выделяются синим цветом, при наведении на них курсором мыши в окне браузера изменяются, например, меняют цвет или выделяются подчеркиванием. При навигации в браузере с помощью клавиатуры текстовые и графические ссылки выделяются прямоугольной пунктирной рамочкой. Посещенная ранее ссылка обычно выделяется цветом, отличным от цвета непосещенной ссылки.
«Битой» ссылкой называют такую гиперссылку, которая ссылается на отсутствующий по каким-либо причинам объект, например, если документ или файл удален или перемещен администратором ресурса, на котором он был расположен, или если сам ресурс недоступен. Обычно в таком случае на странице появляется сообщение с кодом ошибки, но это происходит не всегда.

[Tour]

Internet Protocol (IP) — межсетевой протокол. Относится к маршрутизируемым протоколам сетевого уровня семейства TCP/IP. Именно IP стал тем протоколом, который объединил отдельные подсети во всемирную сеть Интернет. Неотъемлемой частью протокола является адресация сети (см. IP-адрес).
Содержание [убрать]
1 Свойства
2 Версия 4
3 Версия 6
4 Пакет (датаграмма)
4.1 Версия 4 (IPv4)
4.2 Версия 6 (IPv6)
5 См. также
6 Ссылки
[править]Свойства

IP объединяет сегменты сети в единую сеть, обеспечивая доставку данных между любыми узлами сети. Он классифицируется как протокол третьего уровня по сетевой модели OSI. IP не гарантирует надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (приходят две копии одного пакета), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прибыть вовсе. Гарантию безошибочной доставки пакетов дают некоторые протоколы более высокого уровня — транспортного уровня сетевой модели OSI, — например, TCP, которые используют IP в качестве транспорта.
[править]Версия 4

Основная статья: IPv4
В современной сети Интернет используется IP четвёртой версии, также известный как IPv4. В протоколе IP этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 4 октета (4 байта). При этом компьютеры в подсетях объединяются общими начальными битами адреса. Количество этих бит, общее для данной подсети, называется маской подсети (ранее использовалось деление пространства адресов по классам — A, B, C; класс сети определялся диапазоном значений старшего октета и определял число адресуемых узлов в данной сети, сейчас используется бесклассовая адресация).
[править]Версия 6

Основная статья: IPv6
В настоящее время вводится в эксплуатацию шестая версия протокола — IPv6, которая позволяет адресовать значительно большее количество узлов, чем IPv4. Эта версия отличается повышенной разрядностью адреса, встроенной возможностью шифрования и некоторыми другими особенностями. Переход с IPv4 на IPv6 связан с трудоёмкой работой операторов связи и производителей программного обеспечения и не может быть выполнен одномоментно. На середину 2010 года в Интернете присутствовало более 3000 сетей, работающих по протоколу IPv6. Для сравнения, на то же время в адресном пространстве IPv4 присутствовало более 320 тысяч сетей, но в IPv6 сети гораздо более крупные, нежели в IPv4.
[править]Пакет (датаграмма)

IP-пакет — форматированный блок информации, передаваемый по вычислительной сети. Соединения вычислительных сетей, которые не поддерживают пакеты, такие как традиционные соединения типа «точка-точка» в телекоммуникациях, просто передают данные в виде последовательности байтов, символов или битов. При использовании пакетного форматирования сеть может передавать длинные сообщения более надежно и эффективно.
[править]Версия 4 (IPv4)
Основная статья: IPv4
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Версия IHL Тип обслуживания Длина пакета
Идентификатор Флаги Смещение фрагмента
Время жизни (TTL) Протокол Контрольная сумма заголовка
IP-адрес отправителя (32 бита)
IP-адрес получателя (32 бита)
Параметры (от 0 до 10-ти 32-х битных слов)
Данные (до 65535 байт минус заголовок)
Версия — для IPv4 значение поля должно быть равно 4.
IHL — (Internet Header Length) длина заголовка IP-пакета в 32-битных словах (dword). Именно это поле указывает на начало блока данных (англ. payload — полезный груз) в пакете. Минимальное корректное значение для этого поля равно 5.
Идентификатор — значение, назначаемое отправителем пакета и предназначенное для определения корректной последовательности фрагментов при сборке датаграммы. Для фрагментированного пакета все фрагменты имеют одинаковый идентификатор.
3 бита флагов. Первый бит должен быть всегда равен нулю, второй бит DF (don’t fragment) определяет возможность фрагментации пакета и третий бит MF (more fragments) показывает, не является ли этот пакет последним в цепочке пакетов.
Смещение фрагмента — значение, определяющее позицию фрагмента в потоке данных. Смещение задается количеством восьми байтовых блоков, поэтому это значение требует умножения на 8 для перевода в байты.
Время жизни (TTL) — число маршрутизаторов, которые должен пройти этот пакет. При прохождении маршрутизатора это число уменьшатся на единицу. Если значения этого поля равно нулю то, пакет должен быть отброшен и отправителю пакета может быть послано сообщение Time Exceeded (ICMP код 11 тип 0).
Протокол — идентификатор интернет-протокола следующего уровня указывает, данные какого протокола содержит пакет, например, TCP или ICMP (см. IANA protocol numbers и RFC 1700). В IPv6 называется «Next Header».
Контрольная сумма заголовка — вычисляется с использованием операций поразрядного сложения 16-разрядных слов заголовка по модулю 2. Сама контрольная сумма является дополнением по модулю один полученного результата сложения.
[править]Версия 6 (IPv6)
Основная статья: IPv6
Позиция в октетах 0 1 2 3
Позиция в битах 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Версия Класс трафика Метка потока
4 32 Длина полезной нагрузки След. заголовок Число переходов
8 64 IP-адрес отправителя
12 96
16 128
20 160
24 192 IP-адрес получателя
28 224
32 256
36 288
Версия — для IPv6 значение поля должно быть равно 6.
Класс трафика — определяет приоритет трафика (QoS, класс обслуживания).
Метка потока — уникальное число, одинаковое для однородного потока пакетов.
Длина полезной нагрузки — длина данных (заголовок IP-пакета не учитывается).
Следующий заголовок — задаёт тип расширенного заголовка (англ. IPv6 extension), который идёт следующим. В последнем расширенном заголовке поле Next header задаёт тип транспортного протокола (TCP, UDP и т. д.) и определяет следующий инкапсулированный уровень.
Число переходов — максимальное число маршрутизаторов, которые может пройти пакет. При прохождении маршрутизатора это значение уменьшается на единицу и по достижении нуля пакет отбрасывается.
[править]См. также

IPsec
IPv4
IPv5
IPv6
IP-адрес
ip (утилита Unix)
ping
127.0.0.1 — localhost: loopback, замыкание на себя
IP посредством почтовых голубей
Множественная адресация
[править]Ссылки

RFC 791 — IP
RFC 1918
RFC 3330 — Специальные диапазоны адресов в IPv4.

[Tour]

HTTP (сокр. от англ. HyperText Transfer Prоtocоl — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является Технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым..
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Содержание [убрать]
1 Преимущества
1.1 Простота
1.2 Расширяемость
1.3 Распространённость
2 Недостатки и проблемы
2.1 Большой размер сообщений
2.2 Отсутствие «навигации»
2.3 Нет поддержки распределённости
3 Программное обеспечение
3.1 Клиенты
3.2 Исходные серверы
3.3 Прокси-серверы
4 История развития
4.1 HTTP/0.9
4.2 HTTP/1.0
4.3 HTTP/1.1
5 Структура протокола
5.1 Стартовая строка
5.2 Методы
5.2.1 OPTIONS
5.2.2 GET
5.2.3 HEAD
5.2.4 POST
5.2.5 PUT
5.2.6 PATCH
5.2.7 DELETE
5.2.8 TRACE
5.2.9 LINK
5.2.10 UNLINK
5.2.11 CONNECT
5.3 Коды состояния
5.4 Заголовки
5.5 Тело сообщения
6 Примеры диалогов HTTP
6.1 Обычный GET-запрос
6.2 Перенаправления
6.3 Докачка и фрагментарное скачивание
7 Основные механизмы протокола
7.1 Частичные GET
7.2 Условные GET
7.3 Согласование содержимого
7.3.1 Управляемое сервером
7.3.2 Управляемое клиентом
7.3.3 Прозрачное согласование
7.4 Множественное содержимое
8 Особенности протокола
9 Примечания
10 Источники
11 См. также
12 Ссылки
[править]Преимущества

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

[править]Большой размер сообщений
Использование текстового формата в протоколе порождает соответствующий недостаток: большой размер сообщений по сравнению с передачей двоичных данных. Из-за этого возрастает нагрузка на оборудование при формировании, обработке и передаче сообщений. Для решения данной проблемы в протокол встроены средства для обеспечения кэширования на стороне клиента, а также средства компрессии передаваемого контента. Нормативными документами по протоколу предусмотрено наличие прокси-серверов, которые позволяют получить клиенту документ с наиболее близкого к нему сервера. Также в протокол было внедрено diff-кодирование, чтобы клиенту передавался не весь документ, а только его изменённая часть.
[править]Отсутствие «навигации»
Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов. Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Предполагалось, что конечный пользователь уже знает URI необходимого ему документа, закачав который, он будет производить навигацию благодаря гиперссылкам. Это вполне нормально и удобно для человека, но затруднительно, когда стоят задачи автоматической обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы лежит полностью на плечах разработчиков приложений, использующих данный протокол.
Например, со стороны клиента используются веб-пауки — специальные программы, которые составляют список ресурсов сервера, проходя по всем найденным гиперссылкам. Со стороны сервера данная проблема решается с помощью карты сайта (англ. site map) — специальной веб-страницы, где перечислены все доступные для посещения ресурсы. Она предназначена не только для людей, играя аналогичную содержанию в книге роль, но и полезна для тех же роботов-пауков, так как позволяет уменьшить глубину — минимальное необходимое количество переходов с главной страницы. Для тех же целей служат файлы формата Sitemap, которые предназначены уже непосредственно для роботов.
Полностью эта проблема решена в расширяющем HTTP протоколе WebDAV с помощью добавленного метода PROPFIND. Данный метод позволяет не только получить дерево каталогов, но и список параметров каждого ресурса.
[править]Нет поддержки распределённости
Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вообще не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается беспомощен. В 1998 году W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием внимания именно на этой области[2]. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.
[править]Программное обеспечение

Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:
Серверы как основные поставщики услуг хранения и обработки информации (обработка запросов).
Клиенты — конечные потребители услуг сервера (отправка запроса).
Прокси для выполнения транспортных служб.
Для отличия конечных серверов от прокси в официальной документации используется термин origin server (рус. исходный сервер). Разумеется, один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.
[править]Клиенты
Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Популярные браузеры (в алфавитном порядке): Epiphany, Google Chrome, Internet Explorer, Konqueror, Mozilla Firefox, Opera, Safari.
См также: Список браузеров и Сравнение браузеров
Для просмотра сохраненного содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. Среди известных HTTrack и Offline Explorer.
При нестабильном соединении для загрузки больших файлов используются менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. В ОС Windows популярны программы Download Master, FlashGet, Free Download Manager, GetRight, ReGet. В Linux — графический менеджер закачек KGet и d4x (Downloader For X). Многие пользователи Linux предпочитают использование Wget — программы для загрузки файлов, которая сама по себе не является менеджером закачек.
Виртуальные атласы, такие как Google Планета Земля и NASA World Wind, тоже используют HTTP.
Нередко протокол HTTP используется программами для скачивания обновлений.
Целый комплекс программ-роботов используется в поисковых системах Интернета. Среди них веб-пауки (краулеры), которые производят проход по гиперссылкам, составляют базу данных ресурсов серверов и сохраняют их содержимое для дальнейшего анализа.
См. также: Список поисковых машин, Архив Интернета
[править]Исходные серверы
Основные реализации: Apache, Internet Information Services (IIS), lighttpd, nginx.
См. также: Список веб-серверов
[править]Прокси-серверы
Основные реализации: Squid, UserGate, Multiproxy, Naviscope, Nginx.
См. также: Список веб-серверов
[править]История развития

[править]HTTP/0.9
HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.
[править]HTTP/1.0
В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0.
[править]HTTP/1.1
Текущая версия протокола, принята в июне 1999 года[прим 1]. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможной более простую организацию виртуального хостинга.
[править]Структура протокола

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
Стартовая строка (англ. Starting line) — определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.
[править]Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
GET URI — для версии протокола 0.9.
Метод URI HTTP/Версия — для остальных версий.
Здесь:
Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.
URI определяет путь к запрашиваемому документу.
Версия (англ. Version) — пара разделённых точкой арабских цифр. Например: 1.0.
Чтобы запросить страницу данной статьи, клиент должен передать строку:
GET /wiki/HTTP HTTP/1.0
Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния Пояснение
Здесь:
Версия — пара разделённых точкой арабских цифр как в запросе.
КодСостояния (англ. Status Code) — три арабские цифры. По коду статуса определяется дальнейшее содержимое сообщения и поведение клиента.
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:
HTTP/1.0 200 OK
[править]Методы
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
[править]OPTIONS
Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовки ответа может включаться информация о поддерживаемых расширениях.
Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера.
Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.
Результат выполнения этого метода не кэшируется.
[править]GET
Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[3] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.
[править]HEAD
Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.
[править]POST
Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET, метод POST не считается идемпотентным[3], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
Сообщение ответа сервера на выполнение метода POST не кэшируется.
[править]PUT
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
[править]PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
[править]DELETE
Удаляет указанный ресурс.
[править]TRACE
Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
[править]LINK
Устанавливает связь указанного ресурса с другими.
[править]UNLINK
Убирает связь указанного ресурса с другими.
[править]CONNECT
Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через не шифрованный прокси.
[править]Коды состояния
Основная статья: Список кодов состояния HTTP
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр[4]. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:
201 Webpage Created
403 Access allowed only for registered users
507 Insufficient Storage
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния.
1xx Informational (рус. Информационный)
В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
2xx Success (рус. Успех)
Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
3xx Redirection (рус. Перенаправление)
Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.
4xx Client Error (рус. Ошибка клиента)
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной мнемотехники[5]
5xx Server Error (рус. Ошибка сервера)
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
[править]Заголовки
Основные статьи: Заголовки HTTP, Список заголовков HTTP
Заголовки HTTP (англ. HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.
Примеры заголовков:
Server: Apache/2.2.11 (Win32) PHP/5.3.0
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/plain; charset=windows-1251
Content-Language: ru
В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до первого двоеточия, называется именем (англ. name), а что после неё — значением (англ. value).
Все заголовки разделяются на четыре основных группы:
General Headers (рус. Основные заголовки) — должны включаться в любое сообщение клиента и сервера.
Request Headers (рус. Заголовки запроса) — используются только в запросах клиента.
Response Headers (рус. Заголовки ответа) — только для ответов от сервера.
Entity Headers (рус. Заголовки сущности) — сопровождают каждую сущность сообщения.
Именно в таком порядке рекомендуется посылать заголовки получателю.
Все необходимые для функционирования HTTP заголовки описаны в основных RFC, ссылки на которые есть в конце этой статьи. При этом если вам не будет хватать существующих, то можете смело вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV.
[править]Тело сообщения

Этот раздел статьи ещё не написан.
Согласно замыслу одного из участников Википедии, на этом месте должен располагаться специальный раздел.
Вы можете помочь проекту, написав этот раздел.
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.
message-body = entity-body
| <entity-body закодированно согласно
Transfer-Encoding>
Поле Transfer-Encoding ДОЛЖНО использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding — это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body) .
Включается или не включается тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD НЕ ДОЛЖНЫ включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) НЕ ДОЛЖНЫ содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.
[править]Примеры диалогов HTTP

[править]Обычный GET-запрос
Запрос клиента:
GET /wiki/страница HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
(пустая строка)
Ответ сервера:
HTTP/1.1 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close

(далее следует запрошенная страница в HTML)
Аналогично выглядит ответ 203. Что существенно, непосредственно запрашиваемые данные отделены от HTTP-заголовков с помощью CRLF CRLF (двух переводов строки).
[править]Перенаправления
Предположим, что у вымышленной компании Example Corp. есть основной сайт по адресу http://example.com и домен-псевдоним example.org. Клиент посылает запрос страницы «О компании» на вторичный домен (часть заголовков опущена):
GET /about.html HTTP/1.1
Host: example.org
User-Agent: MyLonelyBrowser/5.0
Так как домен example.org не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке Location целевой URI:
HTTP/1.x 301 Moved Permanently
Location: http://example.com/about.html#contacts
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.4
Content-Type: text/html; charset=windows-1251
Content-Length: 110
(пустая строка)
<html><body><a href="http://example.com/about.html#contacts">Click here</a></body></html>
В заголовке Location можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён коротенький HTML-документ с ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок Content-Type содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URL.
Допустим, эта же компания Example Corp. имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим ccTLD. Запрос главной страницы основного сайта example.com может выглядеть так:
GET / HTTP/1.1
Host: example.com
User-Agent: MyLonelyBrowser/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Сервер принял во внимание заголовок Accept-Language и сформировал ответ с временным перенаправлением на российский сервер example.ru, указав его адрес в заголовке Location:
HTTP/1.x 302 Found
Location: http://example.ru/
Cache-Control: private
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.6
Content-Type: text/html; charset=windows-1251
Content-Length: 82
(пустая строка)
<html><body><a href="http://example.ru">Example Corp. Россия</a></body></html>
Обратите внимание на заголовок Cache-Control. Значение «private» сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться только на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.
Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary Redirect).
[править]Докачка и фрагментарное скачивание
Допустим, вымышленная организация предлагает скачать с сайта видео прошедшей конференции по адресу http://example.org/conf-2009.avi объёмом примерно 160 МБ. Рассмотрим, как происходит докачивание этого файла в случае сбоя и как менеджер закачек организовал бы многопоточную загрузку нескольких фрагментов.
В обоих случаях клиенты произведут свой первый запрос наподобие этого:
GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://example.org/
Заголовок Referer указывает, что файл был запрошен с главной страницы сайта. Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы сайта. Без него сервер может ответить 403 (Access Forbidden), если не допускаются запросы с других сайтов. В нашем случае сервер вернул успешный ответ:
HTTP/1.1 200 OK
Date: Thu, 19 Feb 2009 12:27:04 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Content-Type: video/x-msvideo
Content-Length: 160993792
Accept-Ranges: bytes
Connection: close
(пустая строка)
(двоичное содержимое всего файла)
Заголовок Accept-Ranges информирует клиента о том, что он может запрашивать у сервера фрагменты, указывая их смещения от начала файла в байтах. Если этот заголовок отсутствует, то клиент может предупредить пользователя, что докачать файл, скорее всего, не удастся. Исходя из значения заголовка Content-Length, менеджер закачек поделит весь объём на равные фрагменты и запросит их по отдельности, организовав несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит 416 (Requested Range Not Satisfiable).
Допустим, на 84-ом мегабайте соединение с Интернетом прервалось и процесс загрузки приостановился. Когда соединение с Интернетом было восстановлено, менеджер закачек автоматически послал новый запрос на сервер, но с указанием выдать содержимое с 84-ого мегабайта:
GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Range: bytes=88080384-
Referer: http://example.org/
Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок Referer, как будто это его самый первый запрос. Указанное значение заголовка Range говорит серверу — «выдай содержимое от 88080384-ого байта до самого конца». В связи с этим сервер вернёт ответ:
HTTP/1.1 206 Partial Content
Date: Thu, 19 Feb 2009 12:27:08 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Accept-Ranges: bytes
Content-Range: bytes 88080384-160993791/160993792
Content-Length: 72913408
Connection: close
Content-Type: video/x-msvideo
(пустая строка)
(двоичное содержимое от 84-ого мегабайта)
Заголовок Accept-Ranges здесь уже не обязателен, так как клиент уже знает об этой возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду 206 (Partial Content). В заголовке Content-Range содержится информация о данном фрагменте: номера начального и конечного байта, а после слэша — суммарный объём всего файла в байтах. Обратите внимание на заголовок Content-Length — в нём указывается размер тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько фрагментов, то Content-Length будет содержать их суммарный объём.
Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла «conf-2009.avi», программа поделила его на 10 равных секций. Начальную менеджер загрузит при самом первом запросе, прервав соединение как только дойдёт до начала второго. Остальные он запросит отдельно. Например, 4-я секция будет запрошена со следующими заголовками (часть заголовков опущена — см. полный пример выше):
GET /conf-2009.avi HTTP/1.0
Range: bytes=64397516-80496894
Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный пример выше):
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 64397516-80496894/160993792
Content-Length: 16099379
(пустая строка)
(двоичное содержимое 4-ой части)
Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он вернёт стандартный ответ 200 (OK) как было показано в самом начале, но без заголовка Accept-Ranges.
См. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.
[править]Основные механизмы протокола

[править]Частичные GET
HTTP позволяет запросить не сразу всё содержимое ресурса, а только указанный фрагмент. Такие запросы называются частичные GET, возможность их выполнения необязательна (но желательна) для серверов. Частичные GET в основном используются для докачки файлов и быстрого параллельного скачивания в нескольких потоках. Некоторые программы скачивают заголовок архива, выводят пользователю внутреннюю структуру, а потом уже запрашивают фрагменты с указанными элементами архива.
Для получения фрагмента клиент посылает серверу запрос с заголовком Range, указывая в нём необходимые байтовые диапазоны. Если сервер не понимает частичные запросы (игнорирует заголовок Range), то он вернёт всё содержимое со статусом 200, как и при обычном GET. В случае успешного выполнения сервер возвращает вместо кода 200 ответ со статусом 206 (Partial Content), включая в ответ заголовок Content-Range. Сами фрагменты могут быть переданы двумя способами:
В ответе помещается заголовок Content-Range с указанием байтовых диапазонов. В соответствии с ними фрагменты последовательно помещаются в основное тело. При этом Content-Length должен соответствовать суммарному объёму всего тела.
Сервер указывает медиа тип multipart/byteranges для основного содержимого и передаёт фрагменты указывая соответствующий Content-Range для каждого элемента (см. также Множественное содержимое).
См. также пример диалога докачки и фрагментарного скачивания.
[править]Условные GET
Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:
Если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET.
Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.
Если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».
Использование метода условный GET направлено на разгрузку сети, так как он позволяет не передавать по сети избыточную информацию.
[править]Согласование содержимого
Согласование содержимого (англ. Content Negotiation) — механизм автоматического определения необходимого ресурса при наличии нескольких разнотипных версий документа. Субъектами согласования могут быть не только ресурсы сервера, но и возвращаемые страницы с сообщениями об ошибках (403, 404 и т. п.).
Различают два основных типа согласований:
Управляемое сервером (англ. Server-Driven).
Управляемое клиентом (англ. Agent-Driven).
Одновременно могут быть использованы оба типа или каждый из них по отдельности.
В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, рус. Прозрачное согласование содержимого, см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.
[править]Управляемое сервером
При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages и User-Agent. Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.
Географическое положение клиента можно определить по удалённому IP-адресу. Это возможно за счёт того что IP-адреса, как и доменные имена, регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»). Следует помнить что такой метод способен определить местоположение максимум с точностью до города (отсюда определяется и страна). При этом информация актуальна только на момент регистрации адресного пространства. То есть, например, если московский провайдер зарегистрирует диапазон адресов с указанием Москвы и начнёт предоставлять доступ клиентам из ближайшего Подмосковья, то его абоненты могут на некоторых сайтах наблюдать что они из Москвы, а не из, к примеру, Красногорска или Дзержинского.
Управляемое сервером согласование имеет несколько недостатков:
Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами — мало. Из-за этого оборудование испытывает избыточную нагрузку.
Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.
[править]Управляемое клиентом
В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш. Основной недостаток — лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержимое.
[править]Прозрачное согласование
Данное согласование полностью прозрачно для клиента и сервера. В данном случае используется общий кэш, в котором содержится список вариантов, как для управляемого клиентом согласования. Если кэш понимает все эти варианты, то он сам делает выбор, как при управляемом сервером согласовании. Это снижает нагрузки с исходного сервера и исключает дополнительный запрос со стороны клиента.
В основной спецификации по протоколу HTTP механизм прозрачного согласования подробно не описан.
[править]Множественное содержимое
Основная статья: MIME
Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/*. Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа типом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed. Параметр boundary означает разделитель между различными типами передаваемых сообщений. Например передаваемый из формы параметр DestAddress передает значение e-mail адреса, а последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата .jpg Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на частичные GET при запросе нескольких фрагментов ресурса. В этом случае используется медиа тип multipart/byteranges.
Со стороны клиента при отправке HTML-формы чаще всего пользуются методом POST. Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data, интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:
POST /send-message.html HTTP/1.1
Host: mail.example.com
Referer: http://mail.example.com/send-message.html
User-Agent: BrowserForDummies/4.67b
Content-Type: multipart/form-data; boundary="Asrf456BGe4h"
Content-Length: (суммарный объём, включая дочерние заголовки)
Connection: keep-alive
Keep-Alive: 300
(пустая строка)
(отсутствующая преамбула)
--Asrf456BGe4h
Content-Disposition: form-data; name="DestAddress"
(пустая строка)
brutal-vasya@example.com
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageTitle"
(пустая строка)
Я негодую
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageText"
(пустая строка)
Привет, Василий! Твой ручной лев, которого ты оставил
у меня на прошлой неделе, разодрал весь мой диван.
Пожалуйста, забери его скорее!
Во вложении две фотки с последствиями.
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое первой фотографии)
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое второй фотографии)
--Asrf456BGe4h--
(отсутствующий эпилог)
В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах <INPUT> и <TEXTAREA>. Параметр filename равен исходному имени файла на компьютере пользователя. Более подробная информация о формировании HTML-форм и вложении файлов в RFC 1867.
[править]Особенности протокола

Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт в заголовке строчку «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это превратило Internet из «академической игрушки» в «коммерческий сервис»: появились компании, основным полем деятельности которых стало предоставление доступа в Internet (компании-провайдеры) и создание сайтов.
[править]Примечания

↑ Впервые спецификация HTTP/1.1 была опубликована в январе 1997 RFC 2068; в современной версии RFC 2616 исправлены опечатки, местами улучшены терминология и оформление. Также разъяснено допустимое поведение клиента (браузера), сервера и прокси-серверов в некоторых сомнительных ситуациях. То есть версия 1.1 появилась всё-таки в 1997 году.
[править]Источники

↑ «Объём HTTP-трафика впервые превысил P2P» — Компьюлента, 22 июня 2007. (Официальный документ от Ellacoya Networks)
↑ «HTTP-NG — объектно-ориентированный протокол передачи гипертекста», «Открытые системы», 29 мая 1998 г.
«(Proposed) HTTP-NG Working Group» — официальная страница W3C по разработке протокола HTTP-NG.
↑ 1 2 HTTP/1.1: Method Definitions (англ.). W3C. Архивировано из первоисточника 21 августа 2011. Проверено 25 марта 2007.
↑ См. первое предложение раздела «6.1.1 Status Code and Reason Phrase» в RFC 2068. На стр. 40 есть также объявление в формате расширенной БНФ-формы (Augmented BNF) «extension-code = 3DIGIT» для кодов расширений.
↑ HTTP errors
[править]См. также

Список кодов состояния HTTP
Заголовки HTTP (список):
Referer
User-Agent
Cookie
Смежные протоколы и технологии:
Протокол HTTPS
Протокол WebDAV
Интерфейс CGI
Протокол SPDY
Протокол SCTP
Протокол Gopher
Программное обеспечение:
Список веб-серверов
Сравнение браузеров
Список UNIX-демонов
Основы:
Всемирная паутина
Веб-сайт
Веб-приложение
Веб-страница
[править]Ссылки

HTTP: тематические медиа-файлы на Викискладе
RFC 1945 — HTTP/1.0 (Май 1996), включает версию 0.9
RFC 2616 — HTTP/1.1 (Июнь 1999); см. также в виде HTML, PostScript и PDF;
Найденные опечатки в спецификации HTTP/1.1
Перевод спецификации HTTP/1.1 (рус.)
Первоначальный HTTP 0.9 Тима Бернерса-Ли (написанный и изданный в 1991 году)
Ранняя версия исходного черновика версии 1.0 1992 года Тима Бернерса-Ли
Пример последовательности HTTP-обмена между браузером и сервером (PDF)
Функционирование HTTP сервера (рус.)

[Tour]

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

[Гоша]

Сообщение от Tour

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

Как ты думаешь, скока Бигу понадобится времени на прочтение, и сколько ещё неизвестных слов, которые захочет расшифровать он найдёт?

Блять, засрали Чеширу серьёзную тему...

[Джокер]

Сообщение от Tour

Сайт (от англ. website: web — «паутина, сеть» и site — «место», буквально «место, сегмент, часть в сети») — совокупность электронных документов (файлов) частного лица или организации в компьютерной сети, объединённых под одним адресом (доменным именем или IP-адресом).

А что такое совокупность?

[Гоша]

Сообщение от Джокер

А что такое совокупность?

Не торопите события батенька! Узнаете в первую брачную ночь!

[мотоупырь]

Теперь я точно знаю, что компьютер, интернет, и корпорацию Скайнет
придумал гражданин ТУР!!!

[Улыбка 45-го калибра]

Ксс-ксс-ксс)))
Беру от 600 тыров, м?
Портфель:
panasonic.ru
beauty.panasonic.ru
shavers.panasonic.ru
cooking.panasonic.ru
lumix.panasonic.ru
econika-style.ru
sviaz-bank.ru
tatler.ru
deti.fm
in-touch.ru
aoyama.ru
colliers.ru
malakut.ru
city-xxi.ru
fkmotors.ru
omnibike.ru
chitaigorod.ru
stripmonodose.ru
conturgroup.ru
dobrosim.ru
alfa-mfo.ru

[Tour]

Сообщение от мотоупырь

Теперь я точно знаю, что компьютер, интернет, и корпорацию Скайнет
придумал гражданин ТУР!!!

нее....википедия....я же написал..))