Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:
Для отличия конечных серверов от прокси в официальной документации используется термин «исходный сервер» (англ. ). Один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.
Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются менеджеры закачек; они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Некоторые виртуальные атласы (такие как Google Планета Земля и NASA World Wind) тоже используют HTTP.
Нередко протокол HTTP используется программами для скачивания обновлений.
Целый комплекс программ-роботов используется в поисковых системах Интернета. Среди них веб-пауки (краулеры), которые производят проход по гиперссылкам, составляют базу данных ресурсов серверов и сохраняют их содержимое для дальнейшего анализа.
Способы активного отображения информации
Представленная в сети информация может быть доступна:
К способам активного отображения информации во Всемирной паутине относятся:
Это деление весьма условно. Так, скажем, блог или гостевую книгу можно рассматривать как частный случай форума, который, в свою очередь, является частным случаем системы управления контентом. Обычно разница проявляется в назначении, подходе и позиционировании того или иного продукта.
Основой HTTP является технология «клиент-сервер», то есть предполагается существование:
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (в частности, для этого используется HTTP-заголовок). Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
Большинство протоколов предусматривает установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. H TTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. H TTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющий клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.
HTTP/1. 1 response messages
HTTP/1.1 200 OK
Response status codes
In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as “404”) and a textual reason phrase (such as “Not Found”). The response status code is a three-digit integer code representing the result of the server’s attempt to understand and satisfy the client’s corresponding request. The way the client handles the response depends primarily on the status code, and secondarily on the other response header fields. Clients may not understand all registered status codes but they must understand their class (given by the first digit of the status code) and treat an unrecognized status code as being equivalent to the x00 status code of that class.
The first digit of the status code defines its class:
4XX (client error)
5XX (server error)
The server failed to fulfill an apparently valid request.
The response header fields allow the server to pass additional information beyond the status line, acting as response modifiers. They give information about the server or about further access to the target resource or related resources.
Each response header field has a defined meaning which can be further refined by the semantics of the request method or response status code.
В рамках второго направления наработки, являющиеся частью семантической паутины, активно используются в качестве инструментов (RSS и другие форматы веб-каналы, OPML, микроформаты XHTML). Частично семантизированные участки дерева категорий «Википедии» помогают пользователям осознанно перемещаться в информационном пространстве, однако, очень мягкие требования к подкатегориям не дают основания надеяться на расширение таких участков. В связи с этим интерес могут представлять попытки составления атласов Знания.
Существует также популярное понятие Web 2.0, обобщающее сразу несколько направлений развития Всемирной паутины.
Примеры диалогов HTTP
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-заголовков с помощью CR, LF, CR, LF.
Предположим, что у вымышленной компании «Example Corp.» есть основной сайт по адресу «http://example.com» и домен-псевдоним «example.org». Клиент посылает запрос страницы «О компании» на вторичный домен (часть заголовков опущена):
Так как домен «example.org» не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке Location целевой URL:
В заголовке Location можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён короткий HTML-документ со ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок Content-Type содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URI.
Допустим, эта же компания «Example Corp.» имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим ccTLD. Запрос главной страницы основного сайта «example.com» может выглядеть так:
Сервер принял во внимание заголовок Accept-Language и сформировал ответ со временным перенаправлением на российский сервер «example.ru», указав его адрес в заголовке Location:
Обратите внимание на заголовок Cache-Control: значение «private» сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться только на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.
Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary Redirect).
Докачка и фрагментарное скачивание
В обоих случаях клиенты произведут свой первый запрос наподобие этого:
Заголовок 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-го мегабайта:
Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок 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.
Этимология и значение слова
Французский термин «informatique» введён в 1962 году Филиппом Дрейфусом, который также предложил перевод на ряд других европейских языков.
Эквиваленты в английском языке
Конференции являются стратегическими событиями научных исследований в области информатики. В ходе этих конференций исследователи из бюджетного и частного секторов встречаются и представляют свои последние работы. Труды этих конференций являются важной частью литературы по информатике.
Чарльзу Бэббиджу приписывают изобретение первого механического компьютера
Аде Лавлейс приписывают написание первого алгоритма, предназначенного для обработки на компьютере
Самые ранние основы того, что впоследствии станет информатикой, предшествуют изобретению современного цифрового компьютера. Машины для расчёта нескольких арифметических задач, такие как счёты, существовали с древности, помогая в таких вычислениях как умножение и деление.
В 1820 году Томас де Кольмар запустил промышленный выпуск механического калькулятора после того, как он создал свой упрощённый арифмометр, который был первой счётной машиной, достаточно прочной и надёжной для ежедневного использования. Чарльз Бэббидж начал проектирование первого автоматического механического калькулятора, его разностной машины, в 1822, что в конечном счёте подало ему идею первого программируемого механического калькулятора, его аналитической машины.
Со временем был достигнут значительный прогресс в удобстве использования и эффективности вычислительной техники. В современном обществе наблюдается явный переход среди пользователей компьютерной техники: от её использования только экспертами и специалистами к использованию всеми и каждым. Изначально компьютеры были весьма дорогостоящими и чтобы их эффективно использовать нужна была помощь специалистов. Когда компьютеры стали более распространёнными и доступными, тогда для решения обычных задач стало требоваться меньше помощи специалистов.
История информатики в СССР
Несмотря на короткую историю в качестве официальной научной дисциплины, информатика внесла фундаментальный вклад в науку и общество. По сути, информатика, наряду с электроникой, является одной из основополагающих наук текущей эпохи человеческой истории, называемой информационной эпохой. При этом информатика является предводителем информационной революции и третьим крупным шагом в развитии технологий, после промышленной революции (1750—1850 н. э.) и неолитической революции (8000-5000 до н. э.).
Для улучшения визуального восприятия веба стала широко использоваться технология CSS, которая позволяет задавать единые стили оформления для множества веб-страниц. Ещё одно нововведение, на которое стоит обратить внимание, — система обозначения ресурсов URN (англ. Uniform Resource Name).
Популярная концепция развития Всемирной паутины — создание семантической паутины. Семантическая паутина — надстройка над существующей Всемирной паутиной, которая призвана сделать размещённую в сети информацию более понятной для компьютеров. Это также концепция сети, в которой каждый ресурс на человеческом языке был бы снабжён описанием, понятным компьютеру. Семантическая паутина открывает доступ к чётко структурированной информации для любых приложений, независимо от платформы и независимо от языков программирования. Программы смогут сами находить нужные ресурсы, обрабатывать информацию, классифицировать данные, выявлять логические связи, делать выводы и даже принимать решения на основе этих выводов. При широком распространении и грамотном внедрении семантическая паутина может вызвать революцию в Интернете. Для создания понятного компьютеру описания ресурса, в семантической паутине используется формат RDF (англ. Resource Description Framework), который основан на синтаксисе XML и использует идентификаторы URI для обозначения ресурсов. Новинки в этой области: RDFS (англ. ) и SPARQL (англ. Protocol And RDF Query Language) (произносится как «спа́ркл»), новый язык запросов для быстрого доступа к данным RDF.
HTTP/1. 1 example of request / response transaction
gzip, deflate, br
Mon, 23 May 2005 22:38:34 GMT
Wed, 08 Jan 2003 23:11:55 GMT
Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
An Example Page
Hello World, this is a very simple HTML document.
Most of the header lines are optional but some are mandatory. When header “Content-Length: number” is missing in a response with an entity body then this should be considered an error in HTTP/1.0 but it may not be an error in HTTP/1.1 if header “Transfer-Encoding: chunked” is present. Chunked transfer encoding uses a chunk size of 0 to mark the end of the content. Some old implementations of HTTP/1.0 omitted the header “Content-Length” when the length of the body entity was not known at the beginning of the response and so the transfer of data to client continued until server closed the socket.
A “Content-Encoding: gzip” can be used to inform the client that the body entity part of the transmitted data is compressed by gzip algorithm.
HTTP/1. 1 request messages
GET /images/logo.png HTTP/1.1
Host: www.example.com
Accept-Language: en
In the HTTP/1.1 protocol, all header fields except Host: hostname are optional.
An HTTP/1.1 request made using telnet. The request message, response header section, and response body are highlighted.
A request method is safe if a request with that method has no intended effect on the server. The methods GET, HEAD, OPTIONS, and TRACE are defined as safe. In other words, safe methods are intended to be read-only. Однако они не исключают побочных эффектов, таких как добавление информации о запросе в файл журнала или списание средств с рекламного аккаунта, поскольку они по определению не запрашиваются клиентом.
Напротив, методы POST, PUT, DELETE, CONNECT и PATCH небезопасны. Они могут изменять состояние сервера или иметь другие последствия, например отправку электронного письма. Поэтому такие методы обычно не используются соответствующими веб-роботами или веб-сканерами; некоторые, кто не соответствует, склонны делать запросы без учета контекста или последствий.
Метод запроса кэшируется, если ответы на запросы с помощью этого метода могут быть сохранены для повторного использования в будущем. Методы GET, HEAD и POST определены как кэшируемые.
Напротив, методы PUT, DELETE, CONNECT, OPTIONS, TRACE и PATCH не кэшируются.
Поля заголовка запроса позволяют клиенту передавать дополнительную информацию за пределы строки запроса, действуя как модификаторы запроса (аналогично параметрам процедуры). Они предоставляют информацию о клиенте, о целевом ресурсе или об ожидаемой обработке запроса.
Каждое HTTP-сообщение состоит из трех частей, которые передаются в указанном порядке:
Сообщения тела могут отсутствовать, но начальная строка и заголовок являются элементами. Исключением является версия протокола 0.9, в которой запрос сообщения содержит только начальный текст, а ответ сообщения — только тело сообщения.
Для версии протокола 1.1 сообщения запроса обязательно следует сохранять заголовок Host.
Стартовые строки представляют собой запрос и ответ. Строка запроса выглядит так:
GET URI — для протокола версии 0.9;
Метод URI HTTP/Версия — для остальных решений.
Чтобы запросить страницу данной статьи, клиент должен передать текст (задан всего один заголовок):
GET /wiki/HTTP HTTP/1.0
Хост: ru.wikipedia.org
Начальная строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснения, где:
Например, начальная строка ответа сервера на предыдущий запрос может выглядеть так:
HTTP/1.0 200 ОК
Метод HTTP (англ. ) — последовательность любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Сервер может использовать любые методы, не существующие обязательные методы для сервера или клиента. Если сервер не распознал указанный клиентский метод, он должен вернуть статус 501 (не реализовано). Если метод сервера известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (метод не разрешен). В обоих случаях серверу следует включить в заголовок сообщения Разрешить использование соответствующих методов.
Кроме методов GET и HEAD, часто применяется метод POST.
Используется для определения возможностей веб-сервера или параметров соединений для конкретного ресурса. В ответ на сервер следует включить заголовок «Разрешить со списком терапевтических методов». Также в заголовке ответа может быть включена информация о дополнительных расширениях.
Предполагается, что запросивший клиент может сохранить тело сообщения для уточнения его сведений. Формат тела и порядок работы с ним в настоящий момент не определен; сервер, пока должен его сосед. Аналогичная ситуация и с человеком на ответном сервере.
Для того, чтобы узнать возможности всего сервера, клиент должен ввести в URI звёздочку — «*». Запросы «ОПЦИИ * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования объекта поддержки сервером протокола HTTP версии 1.1.
Результат выполнения этого метода не кэшируется.
Используется для определения отображаемого ресурса. С помощью метода GET можно также запустить какой-либо процесс. В этом случае в теле ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:GET /path/resource?param1=value1¶m2=value2 HTTP/1.1
Кроме обычного метода GET, существуют ещё
Порядок выполнения подобных запросов определяется стандартами отдельно.
Аналогичный метод GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки ресурса (URL-адреса проверки) и для того, чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая.
При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
Сообщение ответа сервера на выполнение метода POST не кэшируется.
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же ресурс был изменён, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или недопустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
Аналогично PUT, но применяется только к фрагменту ресурса.
Удаляет указанный ресурс.
Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси.
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния
Заголовки HTTP (англ. ) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. R FC 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
В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до двоеточия, называется именем (англ. ), а что после него — значением (англ. ).
Все заголовки разделяются на четыре основных группы:
Именно в таком порядке рекомендуется посылать заголовки получателю.
Тело HTTP-сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.
Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, применённого приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding — это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта.
Включается или не включается тело сообщения в сообщение ответа — зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.
Так выглядит самый первый веб-сервер, разработанный Тимом Бернерсом-Ли
Изобретателями всемирной паутины считаются Тим Бернерс-Ли и, в меньшей степени, Роберт Кайо. Тим Бернерс-Ли является автором технологий HTTP, URI/URL и HTML. В 1980 году он работал в Европейском совете по ядерным исследованиям (фр. conseil européen pour la recherche nucléaire, ) консультантом по программному обеспечению. Именно там, в Женеве (Швейцария), он для собственных нужд написал программу «Энквайр» (англ. , можно вольно перевести как «Дознаватель»), которая использовала случайные ассоциации для хранения данных и заложила концептуальную основу для Всемирной паутины.
Развитие информационных технологий
В 1989 году, работая в CERN над внутренней сетью организации, Тим Бернерс-Ли предложил глобальный гипертекстовый проект, теперь известный как «Всемирная паутина». Проект подразумевал публикацию гипертекстовых документов, связанных между собой гиперссылками, что облегчило бы поиск и консолидацию информации для учёных CERN. Для осуществления проекта Тимом Бернерсом-Ли (совместно с его помощниками) были изобретены идентификаторы URI, протокол HTTP и язык HTML. Это технологии, без которых уже нельзя себе представить современный Интернет. В период с 1991 по 1993 год Бернерс-Ли усовершенствовал технические спецификации этих стандартов и опубликовал их. Но, всё же, официально годом рождения Всемирной паутины нужно считать 1989 год.
В рамках проекта Бернерс-Ли написал первый в мире веб-сервер, называвшийся «httpd», и первый в мире гипертекстовый веб-браузер, называвшийся «WorldWideWeb». Этот браузер был одновременно и WYSIWYG-редактором (сокр. от англ. what you see is what you get — что видишь, то и получишь), его разработка была начата в октябре 1990 года, а закончена в декабре того же года. Программа работала в среде NeXTStep и начала распространяться по Интернету летом 1991 года.
Первый в мире веб-сайт был размещён Бернерсом-Ли 6 августа 1991 года на первом веб-сервере, доступном по адресу http://info.cern.ch/, (здесь архивная копия). Ресурс определял понятие «Всемирной паутины», содержал инструкции по установке веб-сервера, использования браузера и т. п. Этот сайт также являлся первым в мире интернет-каталогом, потому что позже Тим Бернерс-Ли разместил и поддерживал там список ссылок на другие сайты.
Первая фотография во Всемирной паутине — группа Les Horribles Cernettes
И всё же теоретические основы веба были заложены гораздо раньше Бернерса-Ли. Ещё в 1945 году Ванна́вер Буш разработал концепцию Memex — вспомогательных механических средств «расширения человеческой памяти». Memex — устройство, в котором человек хранит все свои книги и записи (а в идеале и все свои знания, поддающиеся формальному описанию) и которое выдаёт нужную информацию с достаточной скоростью и гибкостью. Оно является расширением и дополнением памяти человека. Бушем было также предсказано всеобъемлющее индексирование текстов и мультимедийных ресурсов с возможностью быстрого поиска необходимой информации. Следующим значительным шагом на пути ко Всемирной паутине было создание гипертекста (термин введён Тедом Нельсоном в 1965 году).
С 1994 года основную работу по развитию Всемирной паутины взял на себя консорциум Всемирной паутины (англ. world wide web consortium, в сокращённой записи ), основанный и до сих пор возглавляемый Тимом Бернерсом-Ли. Данный консорциум — организация, разрабатывающая и внедряющая технологические стандарты для Интернета и Всемирной паутины. Миссия W3C: «Полностью раскрыть потенциал Всемирной паутины путём создания протоколов и принципов, гарантирующих долгосрочное развитие Сети». Две другие важнейшие задачи консорциума — обеспечить полную «интернационализа́цию Сети́» и сделать Сеть доступной для людей с ограниченными возможностями.
W3C разрабатывает для Интернета единые принципы и стандарты (называемые «рекомендациями», англ. ), которые затем внедряются производителями программ и оборудования. Таким образом достигается совместимость между программными продуктами и аппаратурой различных компаний, что делает Всемирную сеть более совершенной, универсальной и удобной. Все рекомендации консорциума Всемирной паутины открыты, то есть не защищены патентами и могут внедряться любым человеком без всяких финансовых отчислений консорциуму.