Основы языка HTML — история создания и биография основателя

Кто создал HTML?

HTML был создан в начале 90-х годов прошлого века английским ученым Тимом Бернерсом-Ли для того, чтобы ученые самых разных областей науки, не разбирающиеся в интернет-технологиях, могли с легкостью создавать различные веб-страницы для обмена научными данными. С тех пор «утекло много воды» и язык HTML много раз совершенствовался и видоизменялся, но основной принцип — доступность всем, был и остается основополагающим.

Сегодня разработкой новых HTML-стандартов занимается организация W3C.

Детство и юность

В 12 лет Тим поступил в частную школу Эмануэль в городке Вэндсворт. Там мальчик начал проявлять интерес к точным наукам. После окончания школы он поступил в колледж при Оксфорде. Однажды его лишили доступа к учебным компьютерам за серьезный проступок – хакерскую атаку (по другой версии, его застукали за компьютером лаборатории ядерной физики за компьютерными играми). В те времена компьютеры были большими, а компьютерное время стоило дорого.
Это обстоятельство натолкнуло Тима на мысль, что он может собрать компьютер сам. Через некоторое время у него появился самодельный компьютер на базе процессора М6800, с обычным телевизором вместо монитора и сломанным калькулятором – вместо клавиатуры.

Карьера

Бернерс-Ли окончил Оксфорд в 1976 году, по специальности «Физика», после чего начал свою карьеру в компании Plessey Telecommunications Ltd. в графстве Дорсет. Сферой его деятельности на тот момент были распределенные транзакции. Уже через пару лет он перешел в другую компанию – DG Nash Ltd, где разрабатывал программное обеспечение для принтеров.
Следующее место работы сыграло решающую роль в судьбе Тима, да и всего человечества. Европейская лаборатория по ядерным исследованиям (CERN, ЦЕРН) располагалась в Женеве (Швейцария). Там Бернерс-Ли разработал программу Enquire (дословный перевод с английского звучит как «дознаватель», «справочная» или «записная книжка»), которая использовала метод случайных ассоциаций. Принцип ее работы, во многом, явился основой для создания Всемирной паутины.
Затем Тим три года работал системным архитектором. А в рамках научной работы в CERN он разработал ряд распределенных систем для сбора данных.
С 1981 по 1984 год Тим Бернерс-Ли работал в компании Image Computer Systems Ltd.

Личная жизнь

Тим Бернерс-Ли эмигрировал в США, где живет и работает в настоящее время, но в душе остаётся истинным англичанином. Поэтому о своей семье предпочитает не распространяться и эта часть биографии краткая. Его дом похож на настоящую крепость, куда журналистов не пускают даже на порог. Известно лишь, что его супругу зовут Ненси Карлсон, они счастливы в браке, есть двое детей. По его собственному мнению, он не стал и никогда не станет истинным американцем.

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

Чего он смог добиться?

Все свои достижения в своей биографии Тим Бернерс-Ли создавал для удобства людей. Единое информационное поле увидело жизнь и существует уже более 20 лет. Тим создал первый в мире сайт и браузер WWW. Программист выпустил несколько книг, где объяснял значимость паутины и моральную сторону вопроса для специалистов IT.

Он стал одним из 6 человек, портреты которых размещены в Зале Славы Всемирной паутины. Провозглашён офицером Ордена Британской Империи. Входит в ТОП 100 величайших умов столетия. В 2004 году произведен Королевой Великобритании в рыцари. Сэр Тим Бернерс-Ли является профессором 16 высших учебных заведений мира. Имеет множество почетных наград.

Как и когда появился HTML язык?

HTML был придуман в 86-м году прошлого века. Инициатором стал ученый из Великобритании Тимон Бернерс-Ли, работающий в Европейской организации по ядерным исследованиям в Женеве.

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

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

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

Но со временем потребности возрастали, что привело к появлению картинок, звука, диаграмм и прочих элементов. В связи с этим выходили новые версии HTML, последней из которых является HTML 5. Современная версия позволяет создавать уже не только сайты, но и web-приложения.

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

1. Тег (дескриптор). HTML полностью состоит из дескрипторов. Они посылают команды веб-браузеру, выполняющему конкретные функции. К примеру, вставляет картинки или создает списки.
2. Атрибут (аргумент). Предназначен для внесения изменений в теге. То есть, он может выровнять по краю или центру абзац/картинку внутри самого тега.
3. Значение. Определяет изменения от атрибутов. Например, при выравнивании текста или изображения, для атрибута можно задать различные значения: текстовые (left либо right), или числовые (размеры картинки по ширине и высоте).

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

Можно заметить, что в начале любого документа в формате HTML есть строка , обозначающая версию HTML и порядок написания и применения тегов. В устаревших версиях HTML было изобилие самых разных вариаций тега DOCTYPE, но в новой версии существует только один – !DOCTYPE.

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

Внутри самого документа находятся 2 блока: и , и выглядит это следующим образом:

В содержатся служебные элементы для поисковиков и браузеров:

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

Какой редактор лучше выбрать

И, правда, какой? Ответ — лучший HTML-редактор тот, который больше подходит под конкретные задачи. Но начать несомненно лучше с текстового редактора, иначе вы рискуете стать «пассажиром с личным водителем» — вроде и машина ваша, но рулите не вы. К тому же, полностью вручную обычно набивается только одна-две странички, которые используются в дальнейшем в качестве шаблона. В наших следующих уроках я буду использовать Notepad++ — многофункциональный, удобный и очень простой HTML-редактор. Да, и абсолютно бесплатный, конечно. :)

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP — 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

Преимущества и недостатки протокола

Многолетняя практика выявила у протокола HTTP немало достоинств и недостатков. Несколько слов о тех и о других.

Достоинства:

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

Недостатки:

• Отсутствие «навигации». У протокола HTTP отсутствуют в явном виде средства навигации среди ресурсов сервера. Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Полностью эта проблема решена в расширяющем HTTP протоколе WebDAV с помощью добавленного метода PROPFIND. Данный метод позволяет не только получить дерево каталогов, но и список параметров каждого ресурса.
• Отсутствие поддержки распределённости. Изначально протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вовсе не приниматься в расчёт. Однако со временем стало очевидно, что при промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается непригоден. В связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next Generation), но этот протокол до сих пор находится на стадии разработки.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию — 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

Методы

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

Существующие методы:

GET: получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

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

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

DELETE: служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

Также HTTP поддерживает и другие методы:

HEAD: аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

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

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

• 202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
• 204 No Content: в теле ответа нет сообщения.
• 205 Reset Content: указание серверу о сбросе представления документа.
• 206 Partial Content: ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

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

• 301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
• 303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
• 304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

• 400 Bad Request: вопрос был сформирован неверно.
• 401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
• 403 Forbidden: сервер не открыл доступ к ресурсу.
• 405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
• 409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

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

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

• 501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
• 503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

message = *(<message-хедер>) CRLF [] = Request-Line | Status-Line <message-хедер>= Field-Name ‘:’ Field-Value

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

• Общие заголовки
• Заголовки запроса
• Заголовки ответа
• Заголовки сущностей

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

general-хедер = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

В заголовках сущностей передаётся мета-информация контента:

entity-хедер = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

</message-хедер></message-хедер>

Формат запроса и ответа

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

Request-Line = Method SP URI SP HTTP-Version CRLF Method = «OPTIONS» | «HEAD» | «GET» | «POST» | «PUT» | «DELETE» | «TRACE»

SP — это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

request-хедер = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP версия
• Код статуса
• Сообщение статуса, понятное для человека

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

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

response-хедер = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

• Age время в секундах, когда сообщение было создано на сервере.
• ETag MD5 сущности для проверки изменений и модификаций ответа.
• Location используется для перенаправления и содержит новый URL адрес.
• Server определяет сервер, где было сформирован ответ.

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

Пример запроса и ответа HTTP

Рассмотрим примеры запроса и ответа HTTP.

Подключение по TCP к серверу www.zvondozvon.ru, порт 80.

————————————————

GET /tehnologii/protokoli HTTP 1.1

Host: www.zvondozvon.ru

HTTP работают в текстовом режиме, нам необходимо подключиться к веб-серверу, например www.zvondozvon.ru к порту 80 по протоколу TCP. Дальше мы пишем запрос, используем метод GET хотим получить ресурс /tehnologii/protokoli и указываем версию протокола по которой мы хотим работать HTTP 1.1. Так как мы используем версию 1.1 нам необходимо указать заголовок host, доменное имя сервера с которым мы работаем www.zvondozvon.ru, этого вполне достаточно для того чтобы веб-сервер нам ответил.

HTTP/1.1 200 OK

Server: nginx

Content-Type: text/html; charset=UTF-8

Content-Length: 5161

˂html lang=”ru-RU”˃

˂head˃

…

˂/html˃

Ответ веб-сервера начинается со статуса 200 ok, обработка запроса произошла успешно, также вначале указываются версия протокола, которая используется HTTP 1.1. Затем идут несколько заголовков реализации веб-сервера nginx, тип передаваемой страницы текста html кодировка utf-8, длина страницы 5161 байт, также здесь могут идти другие заголовки, которые вам передал сервер.

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