HTTP | MDN

Протокол передачи гипертекста (Hypertext Transfer Protocol — HTTP) — это прикладной протокол для передачи гипертекстовых документов, таких как HTML. Он создан для связи между веб-браузерами и веб-серверами, хотя в принципе HTTP может использоваться и для других целей. Протокол следует классической клиент-серверной модели, когда клиент открывает соединение для создания запроса, а затем ждёт ответа. HTTP — это протокол без сохранения состояния, то есть сервер не сохраняет никаких данных (состояние) между двумя парами «запрос-ответ». Несмотря на то, что HTTP основан на TCP/IP, он также может использовать любой другой протокол транспортного уровня с гарантированной доставкой.

Узнайте, как использовать HTTP, благодаря учебникам и руководствам.

Обзор HTTP

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

HTTP-кеширование (HTTP Cache)

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

HTTP-куки (HTTP cookies)

Как работают куки, можно почитать в RFC 6265. При обслуживании HTTP-запроса сервер может отправить в ответе HTTP-заголовок Set-Cookie. После этого значение куки посылается клиентом с каждым запросом к этому серверу. Делается это в форме заголовка запроса Cookie. Дополнительно можно указать истечение срока куки, а так же ограничения для специфического домена или пути.

Контроль доступа (совместное использование ресурсов между разными источниками, HTTP access control (CORS))

Межсайтовые HTTP-запросы (кросс-сайтовые) — это HTTP-запросы к ресурсам, находящимся в домене, отличающемся от того, с которого производится запрос. Например, HTML-страница, загружаемая с домена А (

http://domaina.example), запрашивает изображение с домена Б (http://domainb. foo), используя тег img (http://domainb.foo/image.jpg). Это происходит постоянно в мире веба: страницы загружают различные ресурсы в кросс-сайтовой манере, включая стили (CSS), изображения, скрипты и другие ресурсы. CORS позволяет разработчикам сайтов контролировать межсайтовые запросы.

Эволюция HTTP

Краткое описание изменений, произошедших в HTTP, начиная с самых ранних версий, заканчивая новой HTTP/2 и далее.

Принципы веб-безопасности Mozilla

Сборник советов для помощи в разработке защищённых веб-приложений.

HTTP-сообщения (HTTP Messages)

Описывает тип и структуру разных видов сообщений HTTP/1.x и HTTP/2.

Обычный сеанс HTTP

Показывает и описывает течение обычного сеанса HTTP.

Управление подключениями в HTTP/1.x

Описывает три модели управления подключениями, доступными в HTTP/1.x, их сильные и слабые стороны.

Контроль предварительной загрузки DNS (Controlling DNS prefetching)

Firefox, как и большинство других браузеров, выполняет предварительную загрузку DNS (DNS prefetching). Это действие, когда браузеры превентивно выполняют разрешение доменных имён (получают имена доменов) для ссылок, по которым пользователь может перейти, а также для ссылок на ресурсы, такие как картинки, CSS, JavaScript. Эта предварительная загрузка выполняется в фоновом режиме, так что вполне вероятно, что к моменту обращения к объектам в документе DNS уже получен. Это уменьшает задержки, когда, например, пользователь кликает на ссылку.

Глубже изучите HTTP с помощью справочников и документации.

Заголовки HTTP-сообщения используются для точного описания загружаемого ресурса или поведения сервера или клиента. Пользовательские заголовки можно добавить, используя X- префикс; другие перечислены в IANA registry, содержание которого в свою очередь определено в RFC 4229. IANA так же поддерживает регистр предложенных новых HTTP-заголовков.

Методы HTTP-запроса

Различные операции, которые выполняются с HTTP:

• GET
• POST
• OPTIONS
• DELETE
• TRACE
• PATCH
• другие

Коды ответа (HTTP response codes)

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

Директивы CSP

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

Полезные инструменты и ресурсы для понимания и отладки HTTP.

Инструменты разработчика Firefox

Сетевой монитор

Mozilla Observatory

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

RedBot

Инструмент для проверки кеширования заголовков.

Принципы работы современных веб-браузеров

Комплексная статья по внутренностям браузеров и потоку запросов через протокол HTTP.

Это нужно понимать всем веб-разработчикам.

• Controlling DNS prefetching
• HTTP pipelining FAQ
• HTTP-куки (HTTP cookies)
• HTTP заголовки
• Basic access authentication
• HTTP контроль доступа (CORS)

Last modified: 28 сент. 2022 г., by MDN contributors

HTTP-кеширование — HTTP | MDN

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

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

Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.

Приватный (private) кеш браузера

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

Общий (shared) прокси-кеш

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

Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохранённые ресурсы.

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

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

• Успешно загруженные ресурсы: ответ 200 OK на запрос методом GET HTML-документов, изображений или файлов.
• Постоянные перенаправления: ответ 301 Moved Permanently («перемещено навсегда»).
• Сообщения об ошибках: ответ 404 Not Found («не найдено»).
• Неполные результаты: ответ 206 Partial Content («частичное содержимое»).

• Ответы на запросы отличные от GET, если есть что-либо, подходящее для использования в качестве ключа кеша.

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

Заголовок

Cache-control

Поле Cache-Control общего заголовка HTTP/1.1 используется для задания инструкций по механизму кеширования как в запросах, так и в ответах. Применяется для задания политик кеширования.

Полное отсутствие кеширования

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

Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate

Кешировать, но проверять актуальность

Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.

Cache-Control: no-cache

Приватные (private) и общие (public) кеши

Директива «public» указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются.

Директива же «private» указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.

Cache-Control: private
Cache-Control: public

Срок действия (Expiration)

Самой важной здесь является директива «max-age=<seconds>» — максимальное время, в течение которого ресурс считается «свежим». В отличие от директивы Expires, она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять «агрессивное» кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).

Подробнее об этом рассказывается в разделе Свежесть ресурса.

Cache-Control: max-age=31536000

Проверка актуальности

При использовании директивы «must-revalidate» кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.

Cache-Control: must-revalidate

Заголовок

Pragma

Pragma является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надёжной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично «Cache-Control: no-cache» когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.

Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии.

До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение «свежим» ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком If-None-Match (en-US) на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок 304 Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.

Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:

Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок «Cache-control: max-age=N», то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок

Expires, и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
Время устаревания (expirationTime) вычисляется следующим образом:

expirationTime = responseTime + freshnessLifetime - currentAge

где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.

Обновление статических ресурсов (Revved resources)

Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их «срок годности» имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.

Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал revving^[1], что можно перевести как «оборачиваемость». Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечёт за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.

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

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

Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок «Cache-control: must-revalidate». Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.

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

Заголовки ETag

Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag, клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.

Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified, то для валидации кешированного документа клиент может выводить в запросах заголовок If-Modified-Since.

При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK, либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.

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

Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary, то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.

Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).

Vary: User-Agent

Поскольку значение заголовка User-Agent различается («varies») у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.

• RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
• Caching Tutorial – Mark Nottingham
• HTTP caching – Ilya Grigorik
• RedBot, инструмент для проверки относящихся к кешу заголовков HTTP .

Last modified: 28 сент. 2022 г., by MDN contributors

Протокол Передачи ГИПЕРтекста HTTP для Чайников ты должен знать

Содержание

• 1 Гипертекст и HTML
• 2 URL — уникальное положение ресурса
• 3 Место протокола HTTP в стеке протоколов TCP/IP 
• 4 Версии протокола HTTP
• 5 Структура пакета HTTP
• 6 Методы HTML
• 7 Статусы HTTP
• 8 Пример запроса HTTP

HTTP расшифровывается, как Hypertext Transfer Protocol — протокол передачи гипертекста.   Этот протокол являются основой системы world wide web, именно его мы используем, когда просматриваем странички в браузере.

Web придумал Тим Бернерс-Ли, когда работал в ЦЕРН в 1989 году. Кроме протокола HTTP, веб включал язык разметки HTML, Web-сервер и Web-браузер. Веб-браузер ЦЕРН работал в текстовом виде. Вскоре после этого, появились графические веб браузеры, которыми оказалось очень легко пользоваться. Именно благодаря графическим браузерам и вебу интернет стал очень популярен. Сейчас Тим Бернерс-Ли является директором консорциума W3C, которая издает стандарты для World Wide Web.  

Гипертекст и HTML

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

Например, тег ˂h2˃ говорит, что дальше идет заголовок Протокол HTTP и закрывающийся тег ˂h2˃ заголовок закончился. Тег ˂u1˃ означает список, а ˂li˃ элемент списка.  

Вот как этот гипертекстовый HTML документ показывает браузер. 

Заголовок Протокол HTTP. Обычный текст, который был указан без разметки “Тим Бернер-Ли в ЦЕРН предложил концепцию Web в 1989 году”. И список. 

URL — уникальное положение ресурса

Большую роль в работе web и http играет URL (Uniform Resource Locator) — уникальное положение  ресурса, по-русски его часто называют ссылка. Это уникальный адрес веб-страницы в интернете. 

Рассмотрим, как устроены ссылки. Например, https://www.zvondozvon.ru/tehnologii/protokoli. Сначала идет название протокола, в нашем случае https. Затем :// и доменное имя сервера www.zvondozvon.ru на котором размещена страница, либо здесь может находиться IP-адрес сервера. После этого через слеш указывается имя конкретной страницы, которую мы хотим загрузить /tehnologii/protokoli.

 URL рассчитаны не только на работу с http и html, но и например с другими протоколами, можно указать защищенный протокол https или протокол ftp. Также не обязательно использовать гипертекст, на веб-серверах могут размещаться обычные текстовые страницы. 

Место протокола HTTP в стеке протоколов TCP/IP 

Протокол http находятся на прикладном уровне в стеке протоколов TCP/IP. 

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

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

Версии протокола HTTP

Есть несколько версий протокола HTTP. Первая, экспериментальная версия HTTP 0.9 была разработана в ЦЕРН в 1991 году. Первая официальная версия HTTP 1.0 была принята в качестве стандарта в 1996 году и почти сразу же после этого в 1997 году была принята расширенная версия протокола HTTP 1. 1. Именно эта версия используется до сих пор. В 2015 году появилась новая версия протокола HTTP 2 сейчас эта версия только вводится в эксплуатацию она поддерживается еще не всеми браузерами и не всеми веб-серверами.

Структура пакета HTTP

Пакет HTTP состоит из 3 частей. Первая часть это запрос, либо со стороны клиента, либо от статус ответа со стороны сервера. Например, запрос GET означает, что клиент просит передать ему web-страницу, которая находится на сервере вот по такому пути GET/tehnologii/protokoli в ответ сервер пересылает статус выполнения операции код и символьное сообщение, например 200 OK. Это означает, что страница нашлась на сервере и сервер передает ее в теле сообщения.

Затем могут идти и заголовки, которых может быть несколько. В версии HTTP 1.0 заголовки были не обязательны, но в версии HTTP 1.1 в запросе обязательно использовать заголовок Host:www.zvondozvon.ru, где указываются доменное имя сервера, у которого вы хотите запросить веб-страницу. Это сделано из-за того, что на одном и том же IP-адресе, может работать несколько веб-сайтов и в web серверу необходимо знать с какого сайта вы хотите загрузить страницу. 

Также могут быть другие заголовки, например тип передаваемого сообщения в примере Content-Type: text/html; charset=UTF-8, размер передаваемого сообщения Content-Length: 5161 байт. 

И затем может идти тело сообщения в котором передается запрашиваемая веб-страница или передаются какие-то параметры на сервер. Тело сообщения является необязательным например, в запросе клиента на передачу веб-страницы с сервера тело не нужно. 

Методы HTML

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

• Самые популярные методы это GET запрос на передачу веб-страницы, именно этот запрос используются чаще всего. 
• POST передача данных на веб-сервер для обработки. Метод post используется например, когда вы пишите комментарии к роликам youtube, остальные методы, кроме get и post используются значительно реже.  
• Метод HEAD запрашивает заголовок страницы, то же самое, что и GET только без тела сообщения, хотя HTTP разрабатывался для передачи веб-страниц, создатели HTTP предусмотрели возможность его использования для работы с ресурсами других типов. 
• Метод PUT помещение ресурса на веб-сервер. 
• Метод DELETE удаление страницы или ресурса с веб-сервера для выполнения этих методов необходимо иметь соответствующие права доступа. 
• Метод TRACE позволяет отслеживать, что происходит со страницей, кто вносит в нее какие изменения. 
• Метод OPTIONS позволяет узнать, какие именно методы поддерживаются для конкретного ресурса на веб-сервере.
• Метод CONNECT позволяет подключиться к веб-серверу через прокси. 

Статусы HTTP

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

• Статусы, которые начинаются на единицу (1ХХ), используются для передачи информационных сообщений.
• Статусы, которые начинаются на двойку (2ХХ), говорят о том, что запрос выполнен успешно, например наиболее популярный статус (200 OK), означает что страница найдена и она передается клиенту.
• Статусы, которые начинаются на тройку (3ХХ), говорят о перенаправлении, например статус 301 — постоянное перенаправление, говорит о том что страница была перемещена на другой адрес и все последующие запросы должны передаваться на этот новый адрес. Статус 307 тоже говорит о перенаправлении, но временном, сейчас доступ к странице можно получить по другому адресу, но через некоторое время необходимо снова обращаться к исходному адресу.
• Статусы, которые начинаются с четверки (4ХХ), говоря о том, что произошла какая-то ошибка на стороне клиента. Чаще всего встречается ошибка 404 — страница, которую запросил клиент не найдена на сервере. Также возможна ошибка 403 доступ к ресурсу, который запросил клиент запрещен и другие ошибки. 
• Статусы начинающиеся на пять (5ХХ) говорят об ошибке на стороне сервера, например 500 — внутренняя ошибка сервера.  

Пример запроса 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 разрывается, можно оставить соединение открытым для последующей работы, но для этого необходимо использовать дополнительный заголовок. 

Продолжение про протокол HTTP читайте в статье постоянное соединение и кэширование протокола HTTP.

HTTP | MDN

Протокол передачи гипертекста (HTTP) — это протокол прикладного уровня для передачи гипермедиа-документов, таких как HTML. Он был разработан для связи между веб-браузерами и веб-серверами, но может использоваться и для других целей. HTTP следует классической модели клиент-сервер, когда клиент открывает соединение для отправки запроса, а затем ждет, пока не получит ответ. HTTP — это протокол без сохранения состояния, что означает, что сервер не сохраняет никаких данных (состояния) между двумя запросами.

Узнайте, как использовать HTTP, с помощью руководств и руководств.

Обзор HTTP

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

HTTP-кэш

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

Файлы cookie HTTP

Принцип работы файлов cookie определяется RFC 6265. При обслуживании HTTP-запроса сервер может отправить Set-Cookie Заголовок HTTP с ответом. Затем клиент возвращает значение файла cookie с каждым запросом к одному и тому же серверу в виде заголовка запроса Cookie . Срок действия файла cookie также может быть установлен на определенную дату или ограничен определенным доменом и путем.

Совместное использование ресурсов между источниками (CORS)

Межсайтовые HTTP-запросы — это HTTP-запросы для ресурсов из домена, отличного от домена ресурса, отправляющего запрос. Например, HTML-страница из домена А ( http://domain.example/) делает запрос изображения в домене B ( http://domainb.foo/image.jpg ) через элемент img . Сегодня веб-страницы очень часто загружают межсайтовые ресурсы, включая таблицы стилей CSS, изображения, сценарии и другие ресурсы. CORS позволяет веб-разработчикам контролировать, как их сайт реагирует на межсайтовые запросы.

Подсказки HTTP-клиента

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

Эволюция HTTP

Краткое описание изменений между ранними версиями HTTP, современным HTTP/2, зарождающимся HTTP/3 и более поздними версиями.

Руководство по веб-безопасности Mozilla

Сборник советов, которые помогут операционным группам создавать безопасные веб-приложения.

HTTP-сообщения

Описывает тип и структуру различных типов сообщений HTTP/1.x и HTTP/2.

Типичный сеанс HTTP

Показывает и объясняет ход обычного HTTP-сеанса.

Управление соединением в HTTP/1.x

Описывает три модели управления соединениями, доступные в HTTP/1.x, их сильные и слабые стороны.

Просмотрите подробную справочную документацию по HTTP.

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

Методы HTTP-запроса

Различные операции, которые можно выполнить с помощью HTTP: GET , POST , а также менее распространенные запросы, такие как OPTIONS , DELETE или TRACE .

Коды ответа состояния HTTP

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

Директивы CSP

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

Полезные инструменты и ресурсы для понимания и отладки HTTP.

Инструменты разработчика Firefox

Сетевой монитор

Обсерватория Мозилла

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

РедБот

Инструменты для проверки заголовков, связанных с кешем.

Как работают браузеры (2011)

Очень подробная статья о внутреннем устройстве браузера и потоке запросов по протоколу HTTP. ОБЯЗАТЕЛЬНО ДЛЯ ПРОЧТЕНИЯ любому веб-разработчику.

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

HTTP — обзор протокола передачи гипертекста

HTTP — обзор протокола передачи гипертекста

 

Новости | HTTP Деятельность | Спецификации | Программного обеспечения | Переговоры | Списки рассылки | IETF | HTTP-расширения | ВебМакс | HTTP-NG | Веб-характеристика | Фон

Теперь, когда расширения HTTP и HTTP/1.1 являются стабильными спецификациями (в то время RFC2616), W3C закрыл действие HTTP.

Попытка пересмотреть HTTP/1.1 началась в 2006 году, что привело к созданию IETF httpbis Рабочая группа. Работа завершена публикацией RFC 723X (см. ниже)

• 2014-06 Опубликован RFC 723X
  • RFC7230: HTTP/1.1, часть 1: синтаксис и маршрутизация сообщений
  • RFC7231: HTTP/1.1, часть 2: семантика и содержимое
  • RFC7232: HTTP/1.1, часть 4: условные запросы
  • RFC7233: HTTP/1.1, часть 5: запросы диапазона
  • RFC7234: HTTP/1.1, часть 6: кэширование
  • RFC7235: HTTP/1.1, часть 7: аутентификация
  Вместе с:
  • RFC7236: начальная регистрация схемы аутентификации HTTP
  • RFC7237: начальная регистрация метода HTTP
  И сопутствующие характеристики:
  • RFC7238: код состояния HTTP 308 (постоянное перенаправление)
  • RFC7239: переадресованное HTTP-расширение
  • RFC7240: предпочитать заголовок для HTTP
• 2014-02 : проекты -26 пересмотренных спецификаций HTTP/1. 1
• 2013-11 : проекты -25 пересмотренных спецификаций HTTP/1.1
• 2013-09 : проекты -24 пересмотренных спецификаций HTTP/1.1
• 2013-07 : проекты -23 пересмотренных спецификаций HTTP/1.1
• 03 2013 : проекты -22 пересмотренных спецификаций HTTP/1.1
• 2012-10 : проекты -21 пересмотренных спецификаций HTTP/1.1
• 2012-07 : проекты -20 пересмотренных спецификаций HTTP/1.1
• 03 2012 : проекты -19 пересмотренных спецификаций HTTP/1.1
• 01.02.2012 : проекты -18 пересмотренных спецификаций HTTP/1.1
• 2011-10 : проекты -17 пересмотренных спецификаций HTTP/1.1
• 2011-06 : проекты -16 пересмотренных спецификаций HTTP/1.1
• 2011-07 : проекты -15 пересмотренных спецификаций HTTP/1. 1
• 2011-06 : draft-ietf-httpbis-content-disp опубликован как RFC 6266
• 2011-04 : проекты -14 пересмотренных спецификаций HTTP/1.1
• 2011-03 : проекты -13 пересмотренных спецификаций HTTP/1.1
• 2010-10 : проекты -12 пересмотренных спецификаций HTTP/1.1
• 2010-08 : проекты -11 пересмотренных спецификаций HTTP/1.1
• 2010-07 : проекты -10 пересмотренных спецификаций HTTP/1.1
• 03 2010 : проекты -09 пересмотренных спецификаций HTTP/1.1
• 2009-11 : проекты -08 пересмотренных спецификаций HTTP/1.1
• 2009-07 : проекты -07 пересмотренных спецификаций HTTP/1.1
• 2009-03 : проекты -06 пересмотренных спецификаций HTTP/1.1
• 2008-11 : проекты -05 ​​пересмотренных спецификаций HTTP/1. 1
• 2008-08 : черновик -00 регистрации методов протокола начальной передачи гипертекста (HTTP)
• 2008-08 : проекты -04 пересмотренных спецификаций HTTP/1.1
• 2008-07 : проект -02 требований безопасности для HTTP
• 2008-06 : проекты -03 пересмотренных спецификаций HTTP/1.1
• 2008-02 : проекты -02 пересмотренных спецификаций HTTP/1.1
• 2007-10: Гипертекст WG Transfer Protocol Bis (httpbis) ожил.
• 2007-06: новая редакция Выпущен RFC2616bis.[HTML версия]
• 2006-10: Началась попытка пересмотра RFC2616, см. Список выпусков, последний черновик [HTML версия] и редакция скопировать [HTML версия].
• 1999-07: W3C Поддерживает HTTP/1.1 Достижение проекта стандарта IETF — (отзывы)
• 1999-06: НОВЫЙ HTTP RFC IETF:
  • RFC 2616: протокол передачи гипертекста — HTTP/1. 1 (Postscript), (PDF) (сжатый текст)
  • RFC 2617: HTTP Аутентификация: базовая и краткая аутентификация доступа
  • Исправления для RFC 2616 и RFC 2617
• 1999-06: HTTP Extension Framework ожидает проверки IESG.
  • Стабильный идентификатор: draft-frystyk-http-extensions-03.txt
• 1999-05: Примечание W3C: Редактирование в Интернете: обнаружение потерянного обновления Проблема с использованием незарезервированной кассы
• 31 марта 2009 г.: Лобзик 2.0.2 Реализует платформу расширений HTTP
.

Рядом вы можете найти

• Обзор производительности HTTP для скорость, которую вы жаждете…
• Форум разработчиков HTTP/1.1 для обсуждение приемов реализации HTTP/1.1, а также совместимости работа

Связанные протоколы

• The HTTP Extension Framework Internet Проект и обсуждения
• WebMux — простой протокол мультиплексирования
• Действия W3C HTTP-NG и обзор HTTP-NG

---

• 16 декабря 1998 г. : Хосе Кахан объявляет на стороне клиента Реализация дайджест-аутентификации в libwww — попробуйте!

См. также временную шкалу HTTP для более старых событий

Рабочая группа HTTP

• Список всех HTTP RFC
  • RFC 2616: Протокол передачи гипертекста — HTTP/1.1
  • RFC 2617: HTTP Аутентификация: базовая и краткая аутентификация доступа
• Предыдущие спецификации и проекты HTTP. Если вы ищете предыдущие черновики, а затем посмотрите историю изменений черновика спецификации HTTP
.
• HTTP IETF работает групповой список Интернет-проектов и RFC
• Распределенный Рабочая группа по разработке и управлению версиями ведет список своих шашки
• Дэвид М. Кристол поддерживает страницу на HTTP Государственное управление — также известные как файлы cookie
• Коэн Холтман поддерживает страницу с прозрачным содержимым HTTP переговоры

Родственные протоколы

Платформа расширений HTTP

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

Протокол мультиплексирования (MUX)

Проект предложения по внедрению поддержки асинхронного обмена сообщениями на уровень ниже HTTP

Обработка идентификаторы фрагментов в перенаправленных URL-адресах

Интернет-черновик с предложением по проблеме, которую оставляет HTTP неопределенные.

HTTP-NG — протокол передачи гипертекста — следующий Поколение

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

Фон

• Обзор времени — Каково состояние времени на Интернет?
• Интересные документы и НЕОБХОДИМО читает! Сборник докладов с семинаров, конференций и т. д.
• Сжатие и HTTP — также ознакомьтесь с полным обзор сжатия
• Классические HTTP-документы — читайте, как это все начал

W3C предлагает сервер Jigsaw, написанный на Java и клиентский API libwww — оба выпущены с полной набор функций HTTP/1.1, включая кэширование и постоянные соединения. Пожалуйста, ознакомьтесь с вкладом W3C в открытый исходный код для подробнее.

Предварительная производительность HTTP/1.1 Оценка Джима Геттиса

Производительность HTTP/1. 1 статья подробно объясняет эксперименты, и недавно представлен к публикации. Эта работа показывает, как вы можете получить столько, сколько в 10 раз по количеству пакетов и в 2 раза по скорости при использовании Конвейерная обработка HTTP/1.1. Первые результаты были представлены на конференции IETF в Сан-Хосе. Декабрь 1996 г. и более полные результаты на заседании Консультативного комитета W3C. в Англии в январе.

Обзор новых функций HTTP/1.1 и изменения по сравнению с HTTP/1.0 Джимом Геттисом

В этой презентации представлен хороший обзор новых функций. Это будет время от времени обновляется по мере поступления. Презентация также доступно для Майкрософт PowerPoint

PEP — механизм расширения для HTTP Хенрик Фристик Нильсен и Рохит Кхаре

Эта презентация была сделана на собрании IETF в Монреаль, июнь 1996 г.

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

[email protected] (архивировано в W3C (см. также с 1994 по архив 2002 г.).

Официальный список рассылки рабочей группы IETF HTTP.

[email protected] (Архив)

Это список рассылки W3C, посвященный продвижению HTTP/1.1. внедрение, чтобы получить достаточный опыт среди членов W3C, чтобы поддержите спецификацию и упростите

разработка программного обеспечения и приложений HTTP/1.1. Список только доступный для членов W3C.

[email protected] (архив)

Это основной общедоступный список рассылки для технических обсуждение среди тех, кто разрабатывает программное обеспечение World Wide Web. Это явно предназначен для совместной разработки новых систем, программное обеспечение, протоколы и документация, которые могут быть полезны для WWW сообщество разработчиков. Общие вопросы от не-разработчиков должны быть отправлены одна из многих групп новостей.

[email protected] (Информация)

Этот список больше не поддерживается и больше не активен. Не отправлять письма на этот адрес!

См. также информацию о HTTP-NG

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

• Текущий Интернет Черновики (идентификаторы)
• Запрос на Комментарии (RFC) и еще один очень приятный интерфейс для RFC
• Информация в Интернете Официальные стандарты протокола и
• Интернет-стандарты Процесс о процессе стандартов IETF.

Рабочие группы, связанные с HTTP

Это рабочие группы IETF. работа над проблемами, непосредственно связанными с HTTP:

• Согласование содержания (conneg) Рабочая группа IETF со списком рассылки и архивами
• HTTP wg (http) со списком рассылки и архивами
• WWW Распределенное создание и управление версиями (webdav) с список рассылки и архивы
• Безопасность веб-транзакций wg (wts)

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

• Применение Протокол доступа к конфигурации wg (acap)
• Протокол интернет-печати (ипп)
• Многопартийность Управление мультимедийными сеансами (музыка)
• Реализация TCP (ткпимпл)

Вы также можете проверить полный список рабочих группы.

Собрания IETF

Также посетите страницу собрания IETF для последняя информация. Мы сохраняем небольшой список заметок из предыдущей рабочей группы по HTTP. встречи на различных собраниях IETF:

Лос-Анджелес , Калифорния, США, март-апрель 1998

Где, как, повестка дня и т. д.

Вашингтон, округ Колумбия, США, декабрь 1997 г.

HTTP-WG заметки со встречи и полный онлайн Труды

Мюнхен, Германия, 11-15 августа 1997 г.

HTTP-WG записи со встречи и полный он-лайн Труды

Мемфис, Теннесси, 7–11 апреля 1997 г.

HTTP-WG заметки со встречи и полный онлайн Труды

Сан-Хосе, Калифорния, 9–13 декабря 1996 г.

HTTP-WG записи со встречи и полный он-лайн разбирательства.

Монреаль, Квебек КАНАДА, 24–28 июня 1996 г.

примечания HTTP-WG от встреча

Другие организации, связанные с IETF

Ненумерованный список организаций, связанных с IETF:

• Интернет-инжиниринг Руководящая группа (IESG), состоящая из региональных директоров IETF. вместе с председателем IETF.
• Целевая группа по исследованиям в Интернете (IRTF) состоит из ряда целенаправленных, долгосрочных, небольших исследовательских Группы. Эти группы работают над темами, связанными с интернет-протоколами, приложений, архитектуры и технологий.
• Совет по архитектуре Интернета (IAB) — это орган Internet Society, отвечающий за общее архитектурные соображения в Интернете.
• Интернет-сообщество (ISOC) — это неправительственная международная организация глобального сотрудничества и координация для Интернета и его межсетевых технологий и Приложения.
• Номера, присвоенные Интернету Орган (IANA) является центральным координатором назначения уникальные значения параметров для интернет-протоколов

• Действие HTTP-NG содержит информацию о бывшем W3C Действие HTTP-NG
• Распространение, кэширование и репликация область содержит много информации о схемах кэширования и масштабируемости
• Протокол доступа к интернет-сообщениям (IMAP) — это метод доступа к электронной почте или доске объявлений. сообщения, которые хранятся на почтовом сервере (возможно, совместно используемом)
• Интернет следующего поколения (NGI) Инициатива. 10 октября 1996 г. президент Клинтон и вице-президент Gore объявила о своей приверженности Интернету следующего поколения (NGI) Инициатива, основанная на сильных программах исследований и разработок по всему миру. Федеральные агентства.
• Страницы веб-роботов — информация о веб-роботах и ​​способах управления ими
• Что такое Интернет Погода? Действительно полезный сервис от UCLA
.
• Несколько других интернет-протоколов относится к HTTP

---

Ив Лафон
, @(#) $Id: Overview.html,v 1.244 11.06.2014 14:21:46 ylafon Exp $

Copyright © 1996-2003 W3C ^® (MIT, ERCIM, Кейо), все права защищены. Ответственность W3C, товарный знак, использование документа и программное обеспечение применяются правила лицензирования. Ваше взаимодействие с этим сайтом соответствует с нашей публикой и Конфиденциальность участников заявления.

Протокол передачи гипертекста (http)

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

• О
• Документы
• Встречи
• История
• Фото
• Расширения электронной почты
• Список архивов »

Примечание: Данные по заключенным РГ иногда неверны.

РГ	Имя		Протокол передачи гипертекста
	Акроним		http
	Район		Область применения (приложение)
	Состояние		Заключено
	Устав		устав-ietf-http-01 Одобренный
	Зависимости документа
Персонал	Стул		Ларри М. Масинтер
Список рассылки	Адрес		[email protected]
	Подписаться		[email protected]
	Архив		http://www. ics.uci.edu/pub/ietf/http/hypermail

Финал Устав для Рабочая группа

Примечание. Эта рабочая группа создана совместно Отделом приложений 9.0625 и зона транспортных услуг.

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

o повышение эффективности,
o расширенные операции,
o расширенное согласование,
o расширенная метаинформация и
o связи с протоколами безопасности.

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

Справочная информация

Первоначальная спецификация протокола HTTP была сохранена в виде гипертекста
, а моментальный снимок был распространен в Интернете в виде проекта между 11/93 и
5/94. Пересмотр спецификации Бернерс-Ли, Филдинг и 906:25 Frystyk Nielsen был распространен в Интернете в виде черновика между
ноября 1994 года и
мая 1995 года. Обзор состояния спецификаций и репозиторий
указателей на ресурсы HTTP можно найти по адресу

http://www.w3.org/hypertext/WWW/Protocols/Overview.html

После создания рабочая группа расширит и дополнит этот документ
, чтобы отразить HTTP/1.0 в том виде, в каком он был реализован веб-клиентами и серверами World-Wide
до ноября 1994 года. В результате 9Спецификация 0625 HTTP/1.0 будет опубликована для рассмотрения в качестве интернет-проекта
и, если будет сочтено целесообразным, будет представлена ​​на рассмотрение IESG
в качестве предлагаемого стандарта или информационного RFC.

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

Также параллельно с вышеуказанными усилиями рабочая группа будет заниматься
в определении (или выборе из различных определений) протокола следующего поколения
для передачи гипертекста (HTTPng).

Описание HTTP/1.0 в том виде, в каком оно обычно используется в настоящее время в Интернете
, было отправлено в информационный документ RFC. Рабочая группа
рассматривает усовершенствования/ограничения текущей практики
, чтобы сформировать спецификацию протокола HTTP, подходящую для возможного рассмотрения
в качестве предлагаемого стандарта.

Пройденные вехи

Свидание	Веха	Связанные документы
Сделанный	Отправьте HTTP/1. 2 в IESG для рассмотрения в качестве предлагаемого стандарта.
Сделанный	Ознакомьтесь с дополнительными функциями для HTTP/1.1
Сделанный	Отправьте HTTP/1.1 в IESG для рассмотрения в качестве предлагаемого стандарта.
Сделанный	Отправьте HTTP/1.1 как Internet-Draft (группа редактирования под руководством Джима Геттиса).
Сделанный	Полный обзор предложения HTTP/1.1 и ожидающих рассмотрения идентификаторов по подгруппам: постоянные соединения; управление кешем и поведение прокси; обсуждение содержания; аутентификация; управление состоянием; выборка диапазона; механизмы расширения; другие новые методы и функции заголовка.
Сделанный	Окончательная проверка проекта HTTPng в IETF в Далласе. Пересмотрите проект HTTPng и отправьте его на рассмотрение IESG в качестве предлагаемого стандарта. Ретроспективный взгляд на деятельность HTTP WG.
Сделанный	Публикация Internet-Drafts на HTTP/1.0
Сделанный	Первоначальная публикация предложения HTTP/1.1 от редакторов документов.
Сделанный	Окончательная проверка проекта HTTP/1.1 в Danvers IETF. Пересмотреть проект HTTP/1.1 и представить его в IESG для рассмотрения в качестве предлагаемого стандарта. Просмотрите прогресс в HTTPng.
Сделанный	Пересмотреть Internet-Draft по HTTP/1.0 и, при желании, представить на рассмотрение IESG в категории, определенной в IETF в Сан-Хосе.
Сделанный	Публикация Internet-Draft на HTTP в соответствии с текущей практикой (HTTP/1.0)
Сделанный	Встреча в IETF в Сан-Хосе в качестве BOF. Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт