Нттр – Нттр — что такое НТТР — 2 ответа

Нттр — что такое НТТР — 2 ответа



Нттр это

Автор Маша Альфер задал вопрос в разделе Прочее компьютерное

что такое НТТР и получил лучший ответ

Ответ от <~F()M!4~>[гуру]
Havai To4to Tebe Predlozhili
а вообще протокол передачи данных
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста» ) — протокол прикладного уровня передачи данных в первую очередь в виде текстовых сообщений. Основой HTTP является технология «клиент-сервер» , то есть предполагается существование потребителей (клиентов) , которые инициируют соединение и посылают запрос, и поставщиков (серверов) , которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука [1].

Источник:

Ответ от 2 ответа[гуру]

Привет! Вот подборка тем с ответами на Ваш вопрос: что такое НТТР

Ответ от Rossoff[гуру]
HyperText Transfer Protocol….
Протокол ​передачи гипертекстовых документов

Ответ от Пользователь удален[активный]
Протокол передачи открытых данных! работает обычно на 80 порту но можно застваить работать на любом !

Ответ от Пользователь удален[гуру]
Hyper Text Transfer Protocol

Ответ от Пользователь удален[мастер]
А билл его знает! Протоколы какие-то, может быть это и есть те самые «Протоколы сионистских мудрецов»? Нужно быть искушенным, однако, во всех этих компьютерных штукеренциях, что бы суметь представить себе, что же это за хэтэтэпэшки такие.

Ответ от Андрей ~S@L@6oH~ Овечко[активный]
Протокол ​передачи гипертекстовых документов

Ответ от 2 ответа[гуру]

Привет! Вот еще темы с похожими вопросами:

HTTP на Википедии
Посмотрите статью на википедии про HTTP

 

Ответить на вопрос:

2oa.ru

от корней до кончиков / Habr

Протокол прикладного уровня HTTP лежит в основе интернета. Он начал свою жизнь в 1991 году как HTTP/0.9, а к 1999 году превратился в HTTP/1.1, который был стандартизирован Инженерным советом Интернета (IETF).

HTTP/1.1 долго всех удовлетворял, но растущие потребности Сети потребовали апгрейда — и в 2015 году приняли HTTP/2. На этом история не закончилась: совсем недавно IETF анонсировал новую версию HTTP/3. Для некоторых это стало неожиданностью и вызвало некоторое замешательство. Если вы не отслеживаете работу IETF, может показаться, что HTTP/3 появился из ниоткуда. Тем не менее, мы можем отследить его происхождение по истории экспериментов и эволюции веб-протоколов, в частности, транспортного протокола QUIC.

Если вы не знакомы с QUIC, мои коллеги по Cloudflare довольно подробно осветили разные аспекты: например, см. статьи о реальных недостатках современного HTTP и подробности о протоколе транспортного уровня. Мы собрали эти и другие материалы на сайте cloudflare-quic.com. А если интересно, обязательно ознакомьтесь с quiche: это наша собственная реализация QUIC, написанная на Rust с открытым исходным кодом.

HTTP/3 — трансляция транспортного протокола QUIC для прикладного уровня. Название HTTP/3 официально утвердили лишь недавно, в 17-й версии черновика (draft-ietf-quic-http-17). Его предложили в конце октября 2018 года, а консенсус был достигнут на встрече IETF 103 в Бангкоке в ноябре.

Раньше НТТР/3 был известен как HTTP по QUIC, а до этого — как HTTP/2 по gQUIC, а ещё раньше — SPDY по gQUIC. Но суть в том, что HTTP/3 — просто новый синтаксис HTTP, который работает на протоколе IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP.

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

Слоёный пирог HTTP/3

Непосредственно перед тем, как сосредоточиться на HTTP, стоит напомнить, что существует два протокола с названием QUIC. Как мы уже объясняли, gQUIC обычно используется как сокращение от Google QUIC (исходный протокол), и QUIC — как версия IETF, которая отличается от gQUIC.

С начала 90-х потребности интернета изменились. У нас появились новые версии HTTP и новый уровень безопасности в виде протокола TLS (Transport Layer Security). В этой статье затронем только TLS, а в других статьях нашего блога можно более подробно изучить тему.

Историю HTTP и TLS невозможно выразить простым списком дат, поскольку некоторые ветви развивались параллельно и перекрывались во времени. Когда вы пытаетесь соединить все точки за почти 30 лет истории интернета, не обойтись без визуализации. Поэтому я сделал такой график: Cloudflare Secure Web Timeline. (примечание: технически это кладограмма, хотя людям более привычно слово «график»).

Ради красоты я отбросил часть информации, сосредоточившись только на успешных ветвях в пространстве IETF. Например, здесь не показаны усилия рабочей группы HTTP-NG консорциума W3, а также некоторые экзотические технологии, произношение которых до сих пор пытаютс объяснить авторы: HMURR (произносится «hummer») и WAKA (произносится «wah-kah»).

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

Обычно стандарты определяют общую компетенцию, сферу применения, ограничения, применимость и другие соображения. Стандарты существуют разных форм и размеров. Они могут быть неформальными (стандарт де-факто) или формальными (согласованными/опубликованными организацией, определяющей стандарты, такой как IETF, ISO или MPEG). Стандарты используются во многих областях, существует даже формальный британский стандарт приготовления чая — BS 6008.

Первые определения протоколов HTTP и SSL были опубликованы за пределами IETF: на графике они отмечены красными линиями. Но повсеместное использование сделало их стандартами де-факто.

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

Стандарты IETF широко известны как RFC. Это сложно объяснить вкратце, поэтому рекомендую статью «Как читать RFC» от сопредседателя рабочей группы QUIC Марка Ноттингема. Рабочая группа или WG — это, по сути, просто список рассылки.

Каждый год проходит три собрания для личных встреч членов всех рабочих групп, если они того пожелают. Повестка дня на эти недели может быть очень насыщенной, времени не хватает для углубленного обсуждения технических вопросов. Поэтому некоторые предпочитают устраивать ещё промежуточные совещания между общими совещаниями IETF. Рабочая группа по QUIC с 2017 года провела несколько промежуточных заседаний, полный список доступен на странице встреч.

На этих совещаниях есть возможность встретиться со специалистами из других организаций, таких как Совет по архитектуре интернета (IAB) или Исследовательская группа Интернет-технологий (IRTF). В последние годы в выходные перед заседанием IETF традиционно проводится хакатон IETF. Здесь разрабатывается реальный код и, что важно, проходят тесты совместимости. Это помогает найти проблемы в спецификациях, которые можно обсудить непосредственно на встрече.

Важно понимать, что RFC не возникают из ниоткуда. Они проходят целый процесс. Обычно он начинается с черновика IETF Internet Draft (I-D), который представляют на рассмотрение. В случае, когда уже опубликована спецификация, подготовка I-D станет простым переформатированием. Срок службы I-D составляет 6 месяцев с даты публикации. Чтобы он оставался активным, необходимо публиковать новые версии. На практике нет ничего страшного в том, что срок I-D истекает. Такое происходит довольно часто. Документы по-прежнему хранятся на веб-сайте IETF и открыты для всех.

На кладограмме черновики представлены фиолетовым цветом. У каждого своё название в формате draft-{автор}-{рабочая группа}-{тема}-{версия}

. Поле WG необязательно, оно может указывать на будущую рабочую группу IETF и иногда меняется. Если I-D утверждён IETF или инициирован непосредственно внутри IETF, то черновик называется draft-ietf-{рабочая группа}-{тема}-{версия}. I-D могут разветвляться, сливаться или затухать. Версия начинается с 00 и с каждым новым проектом увеличивается на единицу. Например, четвёртый черновик получит номер версии 03. Каждый раз при изменении названия I-D его версия сбрасывается до 00.

Важно отметить, что любой желающий может представить в IETF свой черновик: их нельзя рассматривать в качестве стандартов. Но если процесс стандартизации достигнет консенсуса и итоговый документ пройдёт проверку, мы получим RFC. На этом этапе имя снова изменяется. Каждый RFC получает уникальный номер, например, RFC 7230. Документы с таким статусом представлены в виде

синих линий.

RFC запрещено изменять. То есть изменения в RFC требуют принятия документа с новым номером. Изменения разрешены только для исправления редакционных или технических ошибок или для простой оптимизации вёрстки. Новые RFC могут полностью заменить старые или дополнить их.

Все документы IETF находятся в открытом доступе на сайте http://tools.ietf.org. Лично мне кажется немного удобнее IETF Datatracker, потому что там визуально отображается путь документа от I-D до RFC.

Ниже пример, который показывает развитие стандарта RFC 1945, то есть HTTP/1.0.

История RFC 1945 в интерфейсе IETF Datatracker

Интересно, что в ходе работы я обнаружил, что вышеприведенная визуализация неверна. По какой-то причине отсутствует draft-ietf-http-v10-spec-05. Поскольку срок жизни I-D составляет 6 месяцев, вероятно, он истёк до принятия RFC, хотя в реальности черновик был активен до августа 1996 года.

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

HTTP появился в 1991 году как протокол HTTP/0.9, а в 1994 году был опубликован черновик draft-fielding-http-spec-00. Вскоре его принял IETF, в результате чего название изменилось на draft-ietf-http-v10-spec-00. После шести редакций черновика в 1996 году был принят стандарт RFC 1945 — HTTP/1.0.

Однако ещё до завершения работы над HTTP/1.0 был запущен отдельный проект HTTP/1.1. Версию черновика draft-ietf-http-v11-spec-00 опубликовали в ноябре 1995-го, а официально приняли как RFC 2068 в 1997 году. Острый глаз заметит, что кладограмма не совсем отражает эту последовательность событий — неудачный глюк инструмента визуализации. Я старался по возможности минимизировать такие проблемы.

В середине 1997 года начался пересмотр HTTP/1.1 как draft-ietf-http-v11-spec-rev-00. Он завершился в 1999 году с публикацией RFC 2616. До 2007 года в мире IETF HTTP всё было тихо. Вернёмся к этому чуть позже.

Переключим внимание на траекторию SSL. Мы видим, что спецификация SSL 2.0 вышла примерно в 1995 году, а SSL 3.0 — в ноябре 1996 года. Интересно, что SSL 3.0 утверждён в стандарте RFC 6101, который появился только в августе 2011 года. Он находится в исторической секции. Согласно IETF, она создана «для документирования идей, которые рассмотрены и отброшены, или протоколов, которые уже существовали к тому времени, когда принято решение их задокументировать». В данном случае был нужен документ IETF с описанием SSL 3.0, чтобы повсеместно использовать его в качестве канонической ссылки.

Нас больше интересует, как SSL вдохновил инженеров на разработку TLS, которая началась с черновика draft-ietf-tls-protocol-00 в ноябре 1996 года. Он прошёл через 6 черновых версий и был опубликован как RFC 2246 — TLS 1.0 в начале 1999 года.

В 1995-1999 годах протоколы SSL и TLS использовались для защиты HTTP-соединений в интернете. Это прекрасно работало как стандарт де-факто. Только в январе 1998 года с публикации черновика draft-ietf-tls-https-00 начался процесс официальной стандартизации HTTPS. Работа завершилась в мае 2000 года публикацией RFC 2616 — HTTP по TLS.

TLS продолжал развиваться с 2000 по 2007 год, с принятием стандартов TLS 1.1 и 1.2. Потом случилась семилетняя пауза, прежде чем начались работы над следующей версией протокола TLS, которую опубликуют в виде draft-ietf-tls-tls13-00 в апреле 2014 года, а после 28 черновиков утвердят как RFC 8446 — TLS 1.3 в августе 2018 года.

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

Официальный статус протокола — важный фактор для организаций, которые думают о его использовании. Формальный процесс стандартизации повышает привлекательность стандарта де-факто, поскольку обычно обеспечивает стабильность. Управление и руководство берёт на себя авторитетная организация, такая как IETF, которая отражает интересы и опыт многих участников. Но следует отметить, что не все формальные стандарты становятся успешными.

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

В каждой организации, определяющей стандарты, обычно есть собственный процесс, ориентированный на её сферу деятельности и участников. Объяснение всех подробностей, как работает IETF, выходит далеко за рамки этой статьи. Если вам это интересно, отличной отправной точкой станет страница «Как мы работаем» на сайте IETF. Как обычно, лучший способ во всём разобраться — принять участие самому. Достаточно присоединиться к списку рассылки или к обсуждению в соответствующем репозитории GitHub.

Cloudflare гордится тем, что одной из первых внедряет новые протоколы, как было с HTTP/2 и другими технологиями. Мы также тестируем экспериментальные и ещё не утверждённые функции, такие как TLS 1.3 и SPDY.

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

Тестирование новшеств — не единственный приоритет. Настоящий инноватор всегда знает, когда следует отложить инновацию до лучших времён. Иногда это относится к протоколам, ориентированным на безопасность: например, Cloudflare отключил SSLv3 по умолчанию из-за уязвимости POODLE. В других случаях протоколы заменяются более технологически продвинутыми: например, мы заменили SPDY на HTTP/2.

Введение и отключение протоколов на Cloudflare представлено оранжевыми линиями. Вертикальные ориентиры помогают соотносить события Cloudflare с соответствующими документами IETF. Например, Cloudflare представила поддержку TLS 1.3 в сентябре 2016 года, а окончательный документ RFC 8446 был опубликован почти два года спустя, в августе 2018 года.

HTTP/1.1 — очень успешный протокол. График не показывает особой активности IETF после 1999 года. Но в реальности годы активного использования протокола дали опыт и проявили скрытые проблемы RFC 2616, в том числе некоторые проблемы совместимости. Кроме того, протокол расширился другими RFC, такими как 2817 и 2818. В итоге, в 2007 году было принято решение начать деятельность по улучшению спецификации HTTP. Она получила название HTTPbis (где «bis» происходит от латинского слова «два», «дважды» или «повтор»). Первоначальный устав новой рабочей группы хорошо описывает проблемы, которые она пыталась решить.

В общем, в HTTPbis начался рефакторинг RFC 2616. Он включает в себя исправления ошибок и внедрение некоторых аспектов из других спецификаций, которые опубликованы в то же время. Было принято решение разделить документ на части. В результате, в декабре 2007 года было опубликовано шесть черновиков:

• draft-ietf-httpbis-p1-messaging
• draft-ietf-httpbis-p2-semantics
• draft-ietf-httpbis-p4-conditional
• draft-ietf-httpbis-p5-range
• draft-ietf-httpbis-p6-cache
• draft-ietf-httpbis-p7-auth

На диаграмме показано, как продвигалась работа в течение длительного семилетнего процесса разработки. До окончательной стандартизации было принято 27 черновиков. В июне 2014 года вышла так называемая серия RFC 723x (где x колеблется от 0 до 5). Председатель рабочей группы по HTTPbis отметил это достижение фразой «RFC2616 мёртв». Если кто не понял, новые документы отправили в архив старый RFC 2616.

Пока IETF занимался доработкой RFC 723x, мир не стоял на месте. Люди продолжали расширять и дополнять HTTP. Среди них и инженеры Google, которые стали экспериментировать с собственным протоколом под названием SPDY (произносится “speedy”). Они заявили, что этот протокол ускоряет загрузку веб-страниц, что является важнейшей функцией HTTP. В конце 2009 года анонсировали первую версию, а в 2010 году быстро появился SPDY v2.

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

У HTTP/0.9, 1.0 и 1.1 много общей семантики. Они также используют общий синтаксис в виде символьных строк, отправляемых через TCP-подключения. SPDY взял семантику HTTP/1.1 и изменил синтаксис на двоичный. Это действительно интересная тема, но сегодня мы не будем углубляться в эту кроличью нору.

Эксперименты со SPDY показали, что изменение синтаксиса HTTP действительно приносит эффект. В то же время важно сохранить существующую семантику. Например, сохранение формата URL для использования https:// позволило избежать многих проблем, которые могли повлиять на внедрение HTTPS.

Увидев некоторые положительные результаты, IETF решил, что пришло время рассмотреть варианты для HTTP/2.0. На слайдах с сессии HTTPbis, состоявшейся во время заседания IETF 83 в марте 2012 года, обозначены требования и цели, которые поставили перед собой разработчики. Там же чётко заявлено: «HTTP/2.0 только означает, что транспортный протокол (wire format) не совместим с HTTP/1.x»

В ходе этой встречи сообществу предложили высказать свои идеи. Среди поданных на рассмотрение черновиков были draft-mbelshe-httpbis-spdy-00, draft-montenegro-httpbis-speed-mobility-00 и draft-tarreau-httpbis-network-friendly-00. В конечном итоге черновик SPDY приняли, а в ноябре 2012 года началась работа над draft-ietf-httpbis-http2-00. После 18 черновиков в течение чуть более двух лет появился RFC 7540 — HTTP/2. К 2015 году синтаксис HTTP/2 ушёл ровно настолько, чтобы сделать HTTP/2 и SPDY несовместимыми.

Эти годы стали очень напряжённым периодом для рабочих групп, которые параллельно проводили рефакторинг HTTP/1.1 и принимали HTTP/2. Это резко контрастирует с многолетним спокойствием в начале 2000-х годов. Обязательно ознакомьтесь с полной кладограммой, чтобы по-настоящему оценить объём проделанной работы.

Несмотря на стандартизацию HTTP/2, эксперименты с SPDY приносят пользу до сих пор. Cloudflare представила поддержку SPDY в августе 2012 года и убрала только в феврале 2018 года, когда наша статистика показала, что её запрашивает менее 4% веб-клиентов. Между тем, вскоре после публикации RFC в декабре 2015 года мы ввели поддержку HTTP/2, когда анализ показал заметную поддержку веб-клиентов.

Протоколы SPDY и HTTP/2 по умолчанию используют TLS. Внедрение универсального SSL в сентябре 2014 года позволило гарантировать, что все пользователи Cloudflare воспользуются новыми протоколами по мере их внедрения.

Google продолжал экспериментировать и до 2015 года выпустил ещё версии SPDY v3 и v3.1. Они также начали работать над протоколом gQUIC, первый черновик которого опубликовали в начале 2012 года.

В ранних версиях gQUIC использовался синтаксис HTTP SPDY v3. Такой выбор имел смысл, потому что HTTP/2 ещё не утвердили. Бинарный синтаксис SPDY упакован в пакеты QUIC, которые отправляются в датаграммах UDP. Это отход от транспорта TCP, на который традиционно полагался HTTP. Вся система в сборе выглядела так:

Слоёный пирог SPDY по gQUIC

Для повышения производительности gQUIC применили хитрые трюки. Один из них — размыть чёткую границу между приложением и транспортом. На практике это означало, что gQUIC поддерживает только HTTP. Эта связь была настолько прочной, что gQUIC, который в то время называли QUIC, стал рассматриваться как кандидат на следующую версию HTTP. Хотя в дальнейшем в QUIC внесли много изменений, по сей день многие считают, что он поддерживает только HTTP. К сожалению, это приводит к постоянной путанице при обсуждении протокола.

gQUIC продолжал развиваться и в конце концов переключился на синтаксис, гораздо более близкий к HTTP/2. Настолько близкий, что большинство людей стали называть его «HTTP/2 по QUIC». Но из-за технических ограничений проявились некоторые очень тонкие различия. Один из примеров связан с сериализацией и обменом заголовками HTTP. Это незначительное различие, но на практике оно означает, что HTTP/2 по gQUIC несовместим с HTTP/2 от IETF.

Последнее, но не менее важное: всегда следует учитывать аспекты безопасности интернет-протоколов. А разработчики gQUIC решили отказаться от TLS в пользу другого подхода под названием QUIC Crypto. Одно из интересных нововведений там — новый метод ускорения рукопожатий. После установки безопасного сеанса с сервером клиент может повторно использовать информацию и зафиксировать «нулевое» время рукопожатия, то есть 0-RTT. Эту хитрость позже включили в протокол TLS 1.3.

Почти.

Теперь мы поняли, как работает стандартизация. Так вот, рассмотрение gQUIC шло по тому же сценарию. В июне 2015 года был представлен первый черновик draft-tsvwg-quic-protocol-00, озаглавленный «QUIC: безопасный и надёжный транспорт на основе UDP для HTTP/2». Но не забывайте, что в конце концов синтаксис протокола почти довели до совместимости с HTTP/2.

Компания Google объявила, что «BoF пройдёт на встрече IETF 93 в Праге». Если вам интересно, что такое BoF, пожалуйста, обратитесь к RFC 6771. Если вкратце, то BoF (Birds of a Feather) — это неформальная встреча на конференции.

По итогу обсуждения с IETF было решено, что у QUIC много преимуществ на транспортном уровне, следует отделить этот протокол от HTTP и вновь ввести чёткое разделение между слоями. Кроме того, для этого протокола решили вернуть рукопожатие на основе TLS (что не так уж плохо, ведь к этому моменту уже разработали TLS 1.3 со схемой 0-RTT).

Примерно через год, в 2016 году, вышел новый набор черновиков:

Вот где снова возникла путаница: draft-shade-quic-http2-mapping-00 называется «Семантика HTTP/2 с использованием транспортного протокола QUIC» и описывает «отображение семантики HTTP/2 по QUIC». Однако это неправильное название. Суть HTTP/2 в изменении синтаксиса при сохранении семантики. Кроме того, «HTTP/2 по gQUIC» никогда не был точным описанием синтаксиса, по причинам, которые я изложил ранее. Имейте это в виду при знакомстве с дальнейшими событиями.

Данная версия QUIC от IETF должна стать совершенно новым транспортным протоколом. Это серьёзное предприятие, поэтому IETF постаралась оценить интерес к проекту со стороны своих членов. Для этого на встрече IETF 96 в Берлине в 2016 году состоялась сессия BoF (слайды). Мне посчастливилось лично присутствовать на том собрании, которое привлекло сотни участников, о чём свидетельствует фотография Адама Роуча. В итоге был достигнут консенсус: QUIC будет принят и стандартизирован в IETF.

Первый черновик IETF QUIC draft-ietf-quic-http-00 для трансляции HTTP на транспорт QUIC логично упростил название протокола до «HTTP по QUIC» (HTTP over QUIC). К сожалению, работу не довели до конца, поэтому по всей организации использовались разные термины HTTP/2. Новый редактор хранилища черновиков стандартов Майк Бишоп увидел проблему и начал исправлять неправильные упоминания HTTP/2. В следующей версии протокола описание изменилось на «сопоставление семантики HTTP на QUIC» (mapping of HTTP semantics over QUIC).

Постепенно, с течением времени и новыми версиями, термин «HTTP/2» стали использовать реже, при необходимости просто указывая ссылки на RFC 7540. Спустя два года в октябре 2018 года вышла семнадцатая по счёту версия черновика (номер 16). Хотя у протокола HTTP over QUIC есть сходство с HTTP/2, по сути это независимый и не совместимый синтаксис HTTP. Тем не менее, для людей, которые не слишком пристально следят за работой IETF (а это очень большой процент населения Земли), название документа не отражает эту разницу. Одна из главных задач стандартизации — содействие коммуникации и оперативной совместимости. А такая простая вещь, как именование, стала главной причиной путаницы в сообществе.

Вспомните, что было сказано в 2012 году: «HTTP/2.0 означает только то, что формат не совместим по транспорту с HTTP/1.х». IETF последовал этому прецеденту. После долгих обсуждений перед и во время конференции IETF 103 всё-таки был достигнут консенсус о переименовании «HTTP over QUIC» в HTTP/3.

Мир стал лучше, и мы можем перейти к более важным дискуссиям.

Иногда названия документов могут сбивать с толку. Вот документы HTTP, описывающие синтаксис и семантику:

• RFC 7230 — Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

По таким названиям можно предположить, что фундаментальная семантика HTTP специфична для конкретной версии HTTP, то есть HTTP/1.1. Но это случайный побочный эффект семейного дерева HTTP. Хорошая новость в том, что рабочая группа HTTPbis пытается решить проблему. Некоторые отважные члены WG начали ещё один раунд пересмотра документа. Эта работа ведётся прямо сейчас и известна как работа HTTP Core (возможно, вы слышали об этой рабочей группе под названиями HTTPtre или HTTPter: здесь тоже всё неоднозначно)Их усилия позволят сжать шесть черновиков до трёх:

• HTTP Semantics (draft-ietf-httpbis-semantics)
• HTTP Caching (draft-ietf-httpbis-caching)
• HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)

В рамках этой новой структуры становится более очевидным, что HTTP/2 и HTTP/3 являются синтаксическими определениями для общей семантики HTTP. Это не означает, что у них нет собственных функций за пределами синтаксиса, но это должно помочь в дальнейшем обсуждении.
Эта статья поверхностно описала процесс стандартизации HTTP в IETF за последние три десятилетия. Особо не касаясь технических деталей, я попытался объяснить, как мы сейчас пришли к HTTP/3. Если вы пропустили середину и ищете суть в одной фразе, то вот она: HTTP/3 — это просто новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP. Здесь много интересных технических нюансов, но придётся отложить их на другой раз.

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

habr.com

Протокол HTTP

HTTP (англ. Hyper Text Transfer Protocol – «протокол передачи гипертекста») — протокол передачи данных прикладного уровня, разработанный специально для обмена информацией между веб-сайтом и пользовательским агентом (браузером). Это один из тех стандартов, на которых основан весь World Wide Web. Взаимодействие поисковых систем с сайтами также проходит в рамках протокола HTTP.

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

Многие термины могут пониматься в разных смыслах. Необходимо сразу договориться, в каком смысле употребляется в этой статье тот или другой термин.

Веб-сервер (сервер) — не компьютер, стоящий в датацентре, а исполняемая на этом компьютере программа, которая принимает запросы и отправляет запрошенные документы.
Пользовательский агент (клиент, User-agent) — программа, посылающая запросы веб-серверу и получающая от него документы. Это может быть ваш браузер, а может быть и сканирующий бот поисковой системы.
Документ — любая отдельная единица информации, имеющая свой адрес в домене. По умолчанию подразумевается HTML-страница, но документами также считаются файлы рисунков, CSS, Java-скриптов и т.п.

В HTTP предусмотрено всего два типа сообщений: запрос клиента и ответ сервера. Клиент шлет серверу запрос, указывая имя домена и адрес внутри домена, по которому должен находиться нужный документ. Сервер принимает сообщение, ищет документ (или запускает скрипт, которым этот документ генерируется) и при успешном завершении отправляет ответное сообщение.
Структура этих сообщений одинакова:

1. Стартовая строка

2. Заголовки

3. Тело сообщения

Стартовую строку и строки заголовков часто называют вместе «заголовком запроса» (или ответа).
Пример стартовой строки запроса:

GET /index.php HTTP/1.1

Передан метод запроса (GET), адрес документа внутри домена и версия протокола, которая используется.
Пример стартовой строки ответа:

HTTP/1.1 200 OK

Передана версия протокола, числовой код статуса (200) и расшифровка статуса (OK).

Заголовки

В заголовках запроса передается дополнительная информация, которая может влиять на дальнейший обмен сообщениями. Обязательно передается имя домена, из которого запрашивается документ. Также может передаваться ожидаемый медиатип документа, возможность приема в сжатом формате, ожидаемый язык для текстовых документов, название пользовательского агента, отправившего запрос. В заголовке могут также передаваться условия запроса. Например, If-Modified-Since: [метка времени] — запрашивается документ при условии, что его содержание изменилсь со времени, указанного в заголовке.

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

При невозможности передачи документа код статуса в сообщении сервера соответствует характеру ошибки, а вместо тела документа передается специальная HTML-страница с текстом сообщения об ошибке. Обратите внимание, что статус ошибки не мешает браузеру отобразить эту страницу.

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

Протоколом в редакции RFC 2616 описано восемь методов для обращения к серверу. Но на сегодняшний день не все они реализованы для большинства веб-серверов, а обязательными к реализации признаны только два. Основные методы, которые нас интересуют и поддерживаются практически всеми веб-серверами — это GET, HEAD и POST.

Метод GET

Это самый обычный метод запроса для получения веб-страницы или другого документа. В ответ на этот запрос сервер должен отыскать (или сформировать) документ и при успешном завершении отправить его клиенту.
Формат запроса:

GET [URI] HTTP[версия протокола]

Тело сообщения в запросе отсутствует.

Метод HEAD

Этот метод аналогичен GET, но с одним отличием: в ответ на запрос HEAD сервер выполняет поиск (или формирование документа), но отправляет только заголовки ответа, не передавая тело сообщения. Таким способом можно проверить существование или доступность документа по данному адресу, получить всю информацию о документе, передаваемую в заголовках, не получая сам документ.
Формат запроса:

HEAD [URI] HTTP[версия протокола]

Тело сообщения в запросе отсутствует.

Метод POST

Этот метод предназначен для передачи данных на сервер — например, данные, введенные в форму, обычно передаются методом POST.
Формат запроса:

POST [URI] HTTP[версия протокола]

Поле [URI] содержит адрес скрипта-обработчика формы, который принимает и обрабатывает данные. В теле сообщения передаются данные, введенные в поля формы в виде [имя_поля=введенное_значение].

Коды статуса

Коды статуса (состояния)¹⁾ отображают результат обработки запроса сервером. Код представлен трехзначным десятичным числом, старший разряд которого указывает на класс ответа. Таким образом, под каждый класс ответов зарезервировано до ста разных кодов статуса. Всего определено пять классов:

1xx: Informational — информационный

Коды от 100 до 199, входящие в этот класс, информируют клиента, что запрос получен. Сообщения с такими статусами содержат только стартовую строку и (если нужно) заголовки, но не содержат тело сообщения. Отправлять что-либо в ответ на это клиент не должен.

2xx: Success — успешно

Сообщения этого класса означают, что запрос успешно получен, интерпретирован и обработан. Из этих кодов статуса нас интересует только 200 «OK» — признак нормального завершения, после которого в теле сообщения клиенту пересылается запрошенный документ.

3xx: Redirection — перенаправление

C этим классом статусов сервер никогда не отправляет тело сообщения, поскольку они предписывают клиенту перенаправление запроса на другой адрес, т.е. выполнение повторного запроса. В этом классе статусов есть одно исключение: статус 304 Not Modified. Он используется в ответ на условные запросы и не вызывает перенаправления, а только сообщает о неизменном состоянии запрошенного документа.

4xx: Client Error — ошибка клиента

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

5xx: Server Error — ошибка сервера

Наверх

wiki.webimho.ru

Составление протокола нттр-авторинга

Изобретение относится к обмену HTTP-сообщениями между HTTP-клиентом и HTTP-сервером. Техническим результатом является обеспечение для устройств-клиентов и серверов возможности использования составных запросов авторинга с одним дискретным обменом. Составной запрос авторинга включает в себя значение специального заголовка типа контент, которое идентифицирует запрос как один из составных запросов авторинга и специальный заголовок расширений, включающий в себя составную команду HTTP-протокола авторинга. Вычислительная система содержит процессор и машиночитаемый носитель, хранящий инструкции, которые при их выполнении побуждают процессор: обрабатывать на серверном вычислительном устройстве стандартные HTTP-запросы и запросы, соответствующие HTTP-протоколу авторинга, посылать указатель на клиентское вычислительное устройство, принимать на серверное вычислительное устройство составные запросы авторинга и обрабатывать на серверном вычислительном устройстве составные запросы авторинга. 3 н. и 7 з.п. ф-лы, 12 ил.

 

Предшествующий уровень техники

На фиг.1 показано сообщение 50 протокола передачи гипертекста (HTTP). Обмен HTTP-сообщениями 50 между HTTP-клиентом 52 и HTTP-сервером 54 хорошо известен в технике обработки данных, выполняемой в системе сервер-клиент. Можно обратиться к различным документам RFC («рабочие предложения» по стандартам) и другим опубликованным документам по проводу деталей, касающихся различных версий и вариантов HTTP. Например, RFC 2616 определяет HTTP версии 1.1. В соответствии с RFC 2616 HTTP-сообщение 50, которое предназначено для HTTP-запроса, имеет строку 54 запроса, такую как “GET/HTTP/1.1” (получить HTTP версии 1.1). HTTP-сообщение 50, которое предназначено для HTTP-ответа, напротив, имеет строку 56 статуса, такую как “HTTP/1.1 200 OK”. За строкой запроса 54 и строкой 56 статуса обычно следуют один или более заголовков, каждый из которых состоит из имени 60 поля, и, в зависимости от конкретного заголовка, ноль или больше тел 62 поля. Сообщение 50 может заканчиваться телом 64 сообщения, в зависимости от типа запроса или ответа. Детали, относящиеся к разделителям, конкретным заголовкам и другим признакам HTTP-сообщений и HTTP-передач, могут быть найдены и в других местах.

На фиг.2 показан пример HTTP-запроса 80 и пример HTTP-ответа 82. HTTP-клиент 52 посылает запрос 80 по сети 84 передачи данных на HTTP-сервер 54, который обрабатывает запрос и возвращает ответ 82. Запрос 80 включает в себя строку 87 запроса и ряд заголовков 88 (некоторые запросы также имеют тело сообщения). Ответ 82 включает в себя строку 89 статуса, заголовки 90 и тело 92 сообщения. HTTP-передачи не обязательно должны проходить по сети, такой как сеть 84; возможен обмен данными между локальным клиентом и локальным сервером, хотя обычно через коммуникационные стеки локальной системы.

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

На фиг.3 показаны некоторые расширения 100 методов и расширения 102 заголовков протокола или расширение HTTP, которое добавляет дистанционную функциональность авторинга поверх HTTP. Эти расширения взяты из RFC 2518, где определены «HTTP-расширения для Web-авторинга и контроля версий» или «WebDAV». WebDAV является расширенной версией HTTP, которая иногда называется протоколом, а иногда называется расширением HTTP. WebDAV-протокол определяет соглашения, методы 100 и заголовки 102 для запросов и ответов, которые в остальном соответствуют HTTP. То есть WebDAV-запросы и ответы следуют базовому формату HTTP-сообщений (например, сообщения 50 на фиг.1). Технически некоторые из команд в методах 100 web-авторинга определены как действительные HTTP-команды, однако их функциональность расширена посредством WebDAV. Например, команда PUT («поместить») является частью HTTP, но WebDAV расширяет ее функциональность до коллекций, каталогов, папок и т.д. Используются те же самые базовые правила HTTP-коммуникаций, используются те же самые ограничители строка/поле/тело, могут использоваться те же самые коды ошибок и базовые HTTP-методы 104 и базовые HTTP-заголовки могут появляться в WebDAV-сообщениях. Например, на обычный HTTP-запрос OPTIONS («опции») WebDAV-совместимый сервер может отвечать ответом, который имеет стандартные HTTP-заголовки, а также один или более нестандартных HTTP-заголовков, которые указывают на доступность одного или более HTTP-расширений на сервере. В принципе, этот способ расширения HTTP позволяет серверам и клиентам манипулировать как базовыми HTTP-коммуникациями, так и их различными расширениями, даже если удаленная система не поддерживает расширение, которое поддерживается локальным образом; неподдерживаемые заголовки и методы обычно игнорируются или обрабатываются постепенно.

WebDAV-расширение для HTTP предоставляет функциональность для создания, изменения и перемещения документов на удаленный сервер (в типовом случае web-сервер). WebDAV-реализации полезны, в числе прочего, для удаленного авторинга документов или ресурсов, обслуживаемых web-сервером. WebDAV-реализации могут также использоваться для общедоступного хранения основанных на Интернет-технологии файлов. Многие операционные системы, такие как Windows, Linux и Mac OSX предоставляют встроенную клиентскую и серверную поддержку для WebDAV, таким образом, предоставляя возможность использования файлов на WebDAV-сервере в некотором смысле подобно тому, как если бы они были сохранены в локальном каталоге.

Методы и заголовки WebDAV полностью документированы в разных местах, однако основные методы включают следующее: PUT — поместить ресурс или коллекцию на сервер; DELETE — удалить ресурс или коллекцию с сервера; PROPFIND — извлечь свойства (как XML) ресурса; PROPPATCH — изменить или удалить свойства ресурса; MKCOL — создать коллекции или каталоги; COPY — копировать ресурс с одного URI на другой на сервере; MOVE — переместить ресурс с одного URI на другой на сервере; LOCK — поместить блокировку на ресурс; UNLOCK — удалить блокировку с ресурса. Некоторыми примечательными заголовками (именами полей) являются: destination — определяет ресурс места назначения для методов, таких как COPY и MOVE; Lock-Token — определяет маркер, который идентифицирует конкретную блокировку; и Timeout — определяет продолжительность блокировки.

Недавно было выявлено, что имеются некоторые неэффективности и слабые места в рамках WebDAV, которые могут стать заметными при определенных обстоятельствах. Фиг.4 показывает временную диаграмму для последовательности связанных запросов авторинга. Предположим, что пользователь HTTP-клиента 52 хотел бы получить и блокировать ресурс на HTTP-сервере 54. Пользователь будет сначала управлять клиентом 52 для получения конкретного ресурса. Клиент 52 будет генерировать и передавать запрос 120 GET на сервер 54. Сервер 54 обрабатывает запрос 120 GET и возвращает соответствующий ответ 122. Время на двустороннее прохождение представляет собой время между моментами, когда клиент 52 передает запрос 120 GET и принимает ответ 122. Как показано на фиг.4, большая часть из времени на двустороннее прохождение может относиться к времени, которое требуется для того, чтобы запрос 120 GET и ответ 122 пересекли сеть. Если пользователю также требуется блокировать ресурс, полученный путем запроса 120 GET, необходим другой цикл информационного обмена: клиент 52 посылает отдельный запрос 124 LOCK; запрос 124 LOCK проходит через сеть; и сервер 54 реагирует ответом 126, который также пересекает сеть. Второй информационный обмен имеет свое собственное время на двустороннее прохождение, которое может включать в себя значительное время передачи по сети. Полное время 128, для того чтобы удовлетворить две связанные потребности клиента 52 (необходимость как получить, так и блокировать ресурс), включает в себя время двух двусторонних прохождений или четырех сетевых передач. Кроме того, два отдельных запроса 120, 124 требуют примерно двойной служебной нагрузки сервера по сравнению с одним запросом, что может вызвать дополнительную задержку, если сервер сильно загружен.

Другая проблема с примером на фиг.4 заключается в том, что запрашиваемый ресурс мог бы быть модифицирован или блокирован другим клиентом (или самим сервером 54) между временем, когда клиент 52 запрашивает ресурс, и временем, когда клиент 52 способен получить блокирование для ресурса. Иными словами, другой запрос может повлиять на ресурс, после того как он получен клиентом 52, но перед тем, как клиент 52 сможет получить блокировку для ресурса, что могло бы вызвать ошибку или неожиданный результат.

Элементарная природа WebDAV и неспособность WebDAV-клиентов и серверов использовать составные или многоаспектные запросы авторинга с одним дискретным обменом могут иметь другие проблемы и неудобства. Без необходимости, некоторые варианты осуществления, обсужденные ниже, могут смягчить некоторые проблемы, ассоциированные с HTTP-авторингом.

Сущность изобретения

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

Некоторые соглашения по информационному обмену между клиентом и сервером расширяют методы составного web-авторинга до протокола web-авторинга, такого как WebDAV. Более конкретно, запрос web-авторинга может быть снабжен специальной информацией заголовка для обозначения первого метода web-авторинга, объединенного со вторым методом web-авторинга, указанным командой в запросе. Клиенты и серверы снабжены методами для использования расширений web-авторинга. Расширенная обработка ошибок может быть использована, чтобы позволить серверам предоставлять более обогащенную информацию об ошибках web-авторинга клиентам.

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

Описание чертежей

Одинаковые ссылочные позиции использованы для обозначения одинаковых элементов на чертежах.

Фиг.1 — HTTP-сообщение.

Фиг.2 — пример HTTP-запроса и пример HTTP-ответа.

Фиг.3 — некоторые расширения методов и расширения заголовков протокола или расширения HTTP, которые добавляют дистанционную функциональность авторинга поверх HTTP.

Фиг.4 — временная диаграмма для последовательности связанных запросов авторинга.

Фиг.5 — некоторые расширения методов web-авторинга и составление расширений заголовков, которые могут быть использованы, чтобы позволить клиентам и серверам объединить два или более связанных методов авторинга в единые информационные обмены между клиентом и сервером.

Фиг.6 — информационный обмен несоставного авторинга и информационный обмен составного авторинга со сходным назначением.

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

Фиг.8 — иллюстрация того, каким образом запросы могут быть форматированы для вызова составного блокирования.

Фиг.9 — механизм объединения методов свойств с методами или командами HTTP или WebDAV.

Фиг.10 — иллюстрация других составных методов.

Фиг.11 — пример запроса метода POSR+PROPFIND+LOCK и соответствующего ответа.

Фиг.12 — таблица обработки ошибок и примеры ответа с использованием расширенной обработки ошибок.

Детальное описание

Фиг.5 показывает некоторые расширения 140 методов web-авторинга и расширения 142 заголовков составления, которые могут быть использованы, чтобы позволить клиентам и серверам объединить два или более относящихся к авторингу методов в единые информационные обмены между клиентом и сервером. Хотя расширения 140 методов характеризуются как «методы», им не требуется использовать команды или строки 54 запроса, которые отличаются от тех, которые определены посредством HTTP или WebDAV. Однако концептуально расширения 140 методов, обсужденные ниже, осуществляют составные методы авторинга. Как описано ниже, эти расширения 140 в действительности составных методов авторинга могут быть реализованы с использованием различных расширений 142 составных заголовков.

На чертежах символы “+” и “|” (вертикальная черта) соответственно обозначают составление (объединение) и «или». Так, например, метод 144 “POST|GET+LOCK|REFRESH|INLOCK” представляет ряд отдельных составных методов: “POST+LOCK”, “POST+UNLOCK”, “GET+LOCK” и т.д. Пояснение того, каким образом расширения 140 методов могут быть реализованы с использованием расширений 142 заголовков, представлено ниже. Методы 144 и 146 обсуждаются со ссылкой на фиг.8. Методы 148 и 150 обсуждаются со ссылкой на фиг.9. Методы 152 и 154 обсуждаются со ссылкой на фиг.10 и 11.

Фиг.6 показывает информационный обмен несоставного авторинга и информационный обмен составного авторинга со сходным назначением. Левая сторона фиг.6 — повторение фиг.4 — показывает поток информационного обмена несоставного авторинга. Правая сторона фиг.6 показывает поток информационного обмена составного авторинга. На правой стороне фиг.6 (составной пример) одиночное сообщение 170 запроса посылается клиентом 52. Сообщение 170 запроса включает в себя информацию, указывающую операцию GET, направленную на ресурс на сервере 174, и информацию, указывающую, что сервер 174 должен также блокировать ресурс для клиента 172. В составном случае, имеет место только один информационный обмен со временем, равным времени одного двустороннего прохождения. Полное время 174 транзакции для составного запроса 170 меньше, чем полное время 120 транзакции несоставных запросов 120, 124. Более того, поскольку сервер 174 может сообщить из сообщения 170 запроса, что желательна блокировка, сервер 174 может немедленно блокировать запрошенный ресурс, таким образом, препятствуя помехам запросу клиента 172 от промежуточного запроса.

На фиг.7 показано, каким образом клиент 172 может определить, доступно ли составление на сервере 174. Как отмечено ранее, желательно (но не обязательно), чтобы клиент мог использовать как составные, так и несоставные запросы авторинга. Также желательно, чтобы сервер мог поддерживать как составные, так и несоставные запросы авторинга. Для этой цели может быть предоставлен некоторый механизм. Предпочтительно, этот механизм предусматривает включение информации в ответ сервера, который указывает, поддерживается ли упомянутое составление сервером. Хотя эта информация может принимать любую форму, использование нового заголовка 190 ответа является удобным, поскольку клиенты обычно игнорируют нераспознанные заголовки в HTTP-ответе. Кроме того, известные алгоритмы для анализа заголовков могут быть легко расширены на процесс для нового заголовка или имени поля. В альтернативном варианте, указатель составления может принимать форму нового значения для стандартного заголовка, специальной строки статуса и т.д.

Для установления доступности составления, клиент 172 выполняет процесс 192, который начинается с посылки стандартного запроса 194 OPTIONS (запрос 194 является лишь одним примером). Процесс 196 на сервере 174 принимает запрос 194 OPTIONS и генерирует ответ такой, как ответ 198, который включает в себя указатель составления, в данном варианте нестандартный заголовок 190 ответа. Действительное имя нестандартного заголовка 190 ответа не является важным, за исключением того, что он должен быть известным заранее для клиента 172, так что когда процесс 192 клиента 172 получает ответ 198, он может распознать его и осуществлять информационный обмен с сервером 174 надлежащим образом.

На фиг.8 показано, каким образом запросы могут форматироваться, чтобы вызвать составное блокирование. Верхняя часть соответствует расширенным методам 144 (см. фиг.5) для блокирования GET и POST, а нижняя часть соответствует расширенным методам 146 для блокирования PUT. В одном варианте осуществления обычные команды 220 HTTP и WebDAV-запросов GET, POST и PUT соединяются с запросами блокирования с использованием различных комбинаций стандартного заголовка 222 Lock-Token и нестандартного или расширенного заголовка 224 lock timeout, например, “X-MSDAVEXTLock-Timeout”. Заголовок 224 lock timeout имеет значение 0 или несколько секунд.

Заголовок 224 lock timeout обозначает создание новой блокировки в соответствии со значением заголовка 224 lock timeout. Если заголовок 222 Lock-Token включен, то заголовок 224 lock timeout сигнализирует обновление существующего блокирования. Если заголовок 224 lock timeout установлен на 0 секунд, то указывается деблокирование (в этом случае заголовок 222 Lock-Token и корректный маркер требуются для деблокирования файла). Кроме того, заголовок 222 Lock-Token и маркер предпочтительно включены в ответ на операцию записи блокированного ресурса. Примерный запрос 228 показывает, что типовой запрос POST+UNLOCK может выглядеть подобным образом. Отметим включение заголовка 222 Lock-Token и заголовка 224 lock timeout.

Обращаясь к команде PUT, объединенной с операцией блокирования, отметим, что заголовок 222 Lock-Token и корректный маркер необходимы для модифицирования блокированного ресурса. Никакого маркера не требуется, если ресурс не блокирован. Если никакой маркер не включен, но время блокирования определено, то возникает естественная логика блокирования; блокирование предоставляется, если блокирование не существует, и PUT, и блокирование отклоняются, если блокирование уже существует. В итоге, если корректный маркер включен в запрос PUT, клиент может выполнять любую операцию PUT, или любую операцию PUT, объединенную с операцией блокирования. Типовой запрос PUT+REFRESH показан запросом 230. Значение lock timeout 120 секунд указывает обновление или переустановку времени жизни блокирования для выполнения в течение еще 120 секунд, и маркер блокирования является ключом, который сервер использует для авторизации как операции PUT, так и операции REFRESH. В предпочтительном варианте заголовок Lock-Token, включенный в операцию «не записывать», игнорируется, то есть “GET+проверить существующее блокирование” не поддерживается.

На фиг.9 показан механизм объединения методов свойств с методами или командами HTTP или WebDAV. Эти составные методы соответствуют методам 148, 150 на фиг.5. Составные методы свойств используют два указателя; значение 240 специального заголовка типа контента (например, “multipart/ MSDAVEXTPrefixEncoded”) и специальный заголовок 242 расширений с различными возможными значениями, такой как “PROPFIND” и “PROPPATCH”. Комбинации в таблице 244 не требуют дополнительного объяснения, и результирующие методы разрешают доступ к ресурсу или его модифицирование при одновременном получении или установке одного или более свойств релевантного ресурса. Кроме того, стандартный заголовок Content-length («длина контента») будет использоваться и будет давать значение всего тела сообщения или полезной нагрузки, что также может включать свойства, а также ресурсы (дополнительно обсуждено ниже).

В соответствии с правилами таблицы 244, показан пример запроса 246 GET+PROPFIND. Отметим включение указания части PROPFIND метода в форме специального заголовка 242 расширений с соответствующим значением или командой.

Хотя в одном варианте осуществления связанные со свойствами методы объединяются в другие методы с использованием заголовков и расширения тела сообщения, также могут использоваться другие подходы. Например, методы WebDAV PROPFIND и PROPPATCH могут быть перегружены с использованием новых заголовков. Кроме того, имеются разные пути для объединения ресурса и набора свойств в теле сообщения. Все из свойств могут быть помещены в отдельные заголовки, поскольку большинство наборов свойств имеют поддающийся управлению размер. Свойства могут быть назначены соответствующим различным заголовкам, хотя это потребовало бы большего кодирования для обработки транспорта свойств. В другом варианте осуществления все свойства (XML-структура) могут быть помещены в один большой заголовок, однако заголовки могут потенциально стать больше, чем буферы, которые некоторые web-серверы выделяют для обработки заголовков.

Возможно, что некоторые реализации могут потребовать одновременно установить свойства (PROPPATCH) и получить свойства (PROPFIND) ресурса. Например, чтобы определить, было ли конкретное свойство установлено надлежащим образом, или чтобы определить, что свойство было установлено прежде, чем оно было изменено посредством PROPPATCH. В этом случае “PROPPATCH” и “PROPFIND” могут быть оба включены, и может быть установлено соглашение для местоположения посылаемых и возвращаемых свойств в теле сообщения.

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

На фиг.9 также показан пример ответа 250 GET+PROPFIND. Отметим, что поле 240 заголовка типа контента сигнализирует наличие тела сообщения из множества частей с использованием специального расширения “multipart/MSDAVEXTPrefixEncodedheader”. Относящаяся к блокированию информация не требуется для метода PUT+PROPPATCH, но может обозначать наличие блокирования серверной стороны. Поле 240 заголовка типа контента обозначает наличие тела 248 сообщения из множества частей в теле 64 сообщения. В принципе, эти многие части разделены полем длины, за которым следуют соответствующие данные, иными словами, тело 64 сообщения несет один или более участков дискретных данных, каждому из которых предшествует соответствующий указатель длины. Размеры полей длины и размеры их данных добавляются к стандартному заголовку Content-length («длина контента»). Примерный ответ 250 на фиг.9 имеет секцию properties («свойства») и секцию resource («ресурс»), каждому из которых предшествует соответствующее поле длины, например, 64-битовое целое число. Поскольку составной авторинг проектируется как HTTP-расширение, то используется стандартное тело 64 HTTP-сообщения. Поскольку может потребоваться, чтобы свойствами можно было обмениваться в сообщении, которое также может включать в себя ресурс, такой как HTML-документ, образование пары «длина-данные» позволяет переносить как свойства, так и ресурсы в одном и том же теле 64 сообщения. Стандартный заголовок Content-length («длина контента») дает полную длину тела 64/248 сообщения и может использоваться, совместно с указателями длины, для анализа существенных частей контента в теле 248 сообщения.

Методы 152, 154 на фиг.5 (POST|GET+PROPFIND+LOCK|REFRESH|UNLOCK, PUT+PROPPATCH+LOCK|REFRESH|UNLOCK) могут быть реализованы путем объединения расширений свойств и блокирования, описанных выше. Поскольку функциональность блокирования и функциональность свойств логически разделены, методы и заголовки, описанные выше, могут легко сосуществовать в сообщении. Фиг.10 показывает другие составные методы. Верхнее сообщение является примером запроса 270 PUT+PROPPATCH+UNLOCK. Отметим, что размер тела, включая размер полей длины, равен 114234. Нижнее сообщение является примером соответствующего ответа 272. Ответ, который является успешным, не отличается от ответа на нормальный запрос PUT. Отсутствие заголовка lock token («маркер блокирования») обозначает успешное деблокирование. Фиг.11 показывает пример запроса 290 метода POST+PROPFIND+LOCK и соответствующий ответ 292. Запрос 290 побуждает сервер поместить ресурс или файл, установить некоторые свойства и деблокировать файл или ресурс.

Фиг.12 показывает таблицу обработки ошибок и примеры ответа 302 с использованием расширенной обработки ошибок. Ряд типов ошибок может возникать при создании ресурса на сервере посредством запроса расширенного HTTP-авторинга, например, недостаточные разрешения, ресурс, контролируемый другим пользователем или не контролируемый совсем, нарушение квоты, или блокированное имя файла или тип файла, наличие вируса и т.д. Другие ошибки, такие как пропуск свойства, могут возникнуть при попытке записи в файл или ресурс. Если ошибка авторинга возникает на сервере, то в типовом случае сервер может иметь обширную информацию системного уровня об ошибке. Ранее, когда модуль или сервер, который реализует методы WebDAV, обнаруживал ошибку, он должен был транслировать эту ошибку в стандартный HTTP-код ошибки. Клиент может пытаться обеспечить полезное сообщение о коде ошибки, возможно, с использованием соответствующей постоянно кодированной строки сообщения. Однако стандартные HTTP-коды ошибок не достаточно разнообразны, чтобы поддерживать количество и типы ошибок, которые пользователь может обнаружить с использованием расширенного HTTP-авторинга. Поэтому факультативно предоставляется расширение для расширения информации об ошибках, возвращаемой клиенту, при сохранении существующего HTTP-кода ошибки, что обеспечивает обратную совместимость. Эта расширенная обработка ошибок выполняется путем включения в ответы информации, специфической для ошибок системного уровня на сервере.

Как можно видеть на фиг.12, расширенная обработка ошибок может быть реализована с использованием нового HTTP-заголовка, например “X-MSDAVEXT_ERROR: Decimal; String”. Часть Decimal является кодом, который отображает ошибку системного уровня, такую как ошибка управления Unix-файла или ошибка Win32. Предпочтительно часть String имеет формат UTF-8.

Рассматривая расширения составления протоколов web-авторинга в общем, следует отметить, что некоторые серверы-посредники могут пытаться интерпретировать запросы и возвращать кэшированные ответы. Поэтому предпочтительно, чтобы клиенты использовали новые расширения или методы только с POST, но не GET. Кроме того, при ответе на конкатенированный метод или команду, как описано выше, сервер должен маркировать ответ, чтобы указать, что он не должен кэшироваться, с использованием, например, заголовка, подобного “cache-control: private” («кэш-управление: приватное»).

Серверный и клиентский процессы для использования методов расширенного составного авторинга являются довольно простыми, при условии соглашений, как описано выше. Общедоступный исходный код и документация могут быть использованы для определения того, каким образом реализовать серверы и клиенты с функциональностью для выполнения элементарных методов авторинга, в частности, функциональностью блокирования и свойств. Эта функциональность может быть выполнена последовательным образом, когда обнаруживается составной метод. Например, хотя ранее сервер мог иметь функцию для обработки метода LOCK и функцию для обработки метода POST, эти функции приближенно могут быть вызваны последовательно, когда принимается составной метод POSR+LOCK.

Хотя выше были описаны HTTP и WebDAV, идеи, описанные выше, как ожидается, будут применимы к любым будущим вариантам или версиям HTTP и WebDAV. Кроме того, стандартный протокол считается ссылающимся на любой будущий или нынешний стандартный протокол.

Дополнительно к аспектам расширенного прохождения ошибок, могут быть предоставлены энергозависимые или энергонезависимые машиночитаемые носители, хранящие информацию для разрешения устройству выполнять процесс обслуживания запросов от клиентов, причем процесс включает в себя обработку стандартных HTTP-запросов get, обработку стандартных HTTP-запросов post и обработку стандартных HTTP-запросов options и отправку ответов соответствующим клиентам; обработку стандартных или нестандартных HTTP-запросов авторинга, которые предписывают устройству блокировать/деблокировать ресурсы, или предписывают устройству получать или устанавливать свойства ресурсов; и если возникают ошибки, обработку HTTP-запросов авторинга, возвращение ответов, содержащих информацию об ошибках, которая не является HTTP-кодом статуса. Информация об ошибках может соответствовать системной ошибке устройства, которое обусловило появление ошибки. Информация об ошибке может включать в себя имя расширенного заголовка ошибки и сопровождающее поле заголовка, содержащее идентификацию и/или описание соответствующей ошибки, и, кроме того, в таком случае поле заголовка может включать в себя код системной ошибки устройства или поле заголовка может включать в себя строку, специально описывающую ошибку, или поле заголовка может включать в себя код системной ошибки устройства (код ошибки, являющийся или идентифицирующий системную ошибку устройства), или системная ошибка содержит ошибку блокирования файла, или ошибку считывания файла или каталога, или ошибку записи файла или каталога.

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

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

В заключение, специалистам в данной области техники должно быть понятно, что запоминающие устройства, используемые для хранения программных инструкций, могут распространяться по сети. Например, удаленный компьютер может хранить пример процесса, описанного как программное обеспечение. Локальный компьютер или компьютер-терминал может получать доступ к удаленному компьютеру и загружать часть или все программное обеспечение для выполнения программы. Альтернативно, локальный компьютер может загружать части программного обеспечения, по мере необходимости, или обрабатывать распределенным образом путем исполнения некоторых инструкций программного обеспечения на локальном терминале, а некоторых — на удаленном компьютере (или компьютерной сети). Специалистам в данной области техники также должно быть понятно, что путем использования обычных методов, известных специалистам в данной области техники, все или часть инструкций программного обеспечения может исполняться специализированной схемой, такой как цифровой процессор сигналов (DSP), программируемая логическая матрица и т.п.

Все из вариантов осуществления и признаков, описанных выше, могут быть реализованы в форме информации, сохраненной на энергозависимом или энергонезависимом носителе, считываемом компьютером или устройством. Это включает, по меньшей мере, носители, такие как ПЗУ на компакт-диске (CD-ROM), магнитные носители, флэш-ПЗУ и т.д., хранящие машиноисполняемые инструкции или исходный код, или любую другую информацию, которая может использоваться для того, чтобы обеспечить возможность вычислительному устройству выполнить различные варианты осуществления. Сюда также должна включаться, по меньшей мере, энергозависимая память, такая как ОЗУ, хранящее информацию, такую как инструкции центрального процессора (CPU), в течение выполнения программы, выполняющей вариант осуществления.

1. Энергозависимый или энергонезависимый машиночитаемый носитель, хранящий информацию для разрешения серверному вычислительному устройству выполнять процесс для обслуживания запросов, причем процесс включает в себя
обработку на серверном вычислительном устройстве стандартных HTTP-запросов get, обработку стандартных HTTP-запросов post и стандартных HTTP-запросов options;
обработку на серверном вычислительном устройстве запросов, которые соответствуют HTTP-протоколу авторинга, причем запросы включают в себя запросы put, запросы copy, запросы move, запросы propfind и запросы proppatch;
посылку указателя на клиентское вычислительное устройство, указывающего, что серверное вычислительное устройство обрабатывает составные запросы авторинга;
прием на серверном вычислительном устройстве составных запросов авторинга, причем каждый составной запрос авторинга включает в себя значение специального заголовка типа контента, которое идентифицирует запрос как один из составных запросов авторинга, и специальный заголовок расширений, включающий в себя составную команду HTTP-протокола авторинга; и
обработку на серверном вычислительном устройстве составных запросов авторигна, которые не соответствуют HTTP-протоколу авторинга, при этом составные запросы содержат запросы put+proppatch и запросы post+propfind.

2. Носитель по п.1, причем процесс дополнительно содержит выполнение функциональности put и функциональности proppatch в ответ на запрос put+proppatch, или выполнение функциональности get и функциональности propfind в ответ на запрос get+propfind, или выполнение функциональности post и функциональности propfind в ответ на запрос post+propfind.

3. Носитель по п.1, причем обрабатываемые запросы, которые не соответствуют HTTP-протоколу авторинга, дополнительно содержат запросы, которые в отдельных запросах определяют как операции post, get или put, так и операции lock, unlock или lock refresh.

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

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

6. Носитель по п.1, причем процесс дополнительно содержит включение набора свойств и ресурса в тело сообщения ответа.

7. Вычислительная система для хранения информации для разрешения устройству выполнять процесс для обслуживания запросов, причем система содержит:
процессор и
машиночитаемый носитель, хранящий инструкции, которые при их исполнении процессором, побуждают процессор
обрабатывать на серверном вычислительном устройстве стандартные HTTP-запросы get, обработку стандартные HTTP-запросы post и стандартные HTTP-запросы options;
обрабатывать на серверном вычислительном устройстве запросы, которые соответствуют HTTP-протоколу авторинга, причем запросы включают в себя запросы put, запросы copy, запросы move, запросы propfind и запросы proppatch;
посылать указатель на клиентское вычислительное устройство, указывающий, что серверное вычислительное устройство обрабатывает составные запросы авторинга;
принимать на серверном вычислительном устройстве составные запросы авторинга, причем каждый составной запрос авторинга включает в себя значение специального заголовка типа контента, которое идентифицирует запрос как один из составных запросов авторинга, и специальный заголовок расширений, включающий в себя составную команду HTTP-протокола авторинга; и
обрабатывать на серверном вычислительном устройстве составные запросы авторигна, которые не соответствуют HTTP-протоколу авторинга, при этом составные запросы содержат запросы put+proppatch и запросы post+propfind.

8. Вычислительная система по п.7, в которой обрабатываемые запросы, которые не соответствуют HTTP-протоколу авторинга, дополнительно содержат запросы, которые в отдельных запросах определяют как операции post, get или put, так и операции lock, unlock или lock refresh.

9. Способ обслуживания запросов, причем способ содержит:
обработку на серверном вычислительном устройстве стандартных HTTP-запросов get, обработку стандартных HTTP-запросов post и стандартных HTTP-запросов options;
обработку на серверном вычислительном устройстве запросов, которые соответствуют HTTP-протоколу авторинга, причем запросы включают в себя запросы put, запросы copy, запросы move, запросы propfind и запросы proppatch;
посылку указателя на клиентское вычислительное устройство, указывающего, что серверное вычислительное устройство обрабатывает составные запросы авторинга;
прием на серверном вычислительном устройстве составных запросов авторинга, причем каждый составной запрос авторинга включает в себя значение специального заголовка типа контента, которое идентифицирует запрос как один из составных запросов авторинга, и специальный заголовок расширений, включающий в себя составную команду HTTP-протокола авторинга; и
обработку на серверном вычислительном устройстве составных запросов авторигна, которые не соответствуют HTTP-протоколу авторинга, при этом составные запросы содержат запросы put+proppatch и запросы post+propfind.

10. Способ по п.9, в котором обрабатываемые запросы, которые не соответствуют HTTP-протоколу авторинга, дополнительно содержат запросы, которые в отдельных запросах определяют как операции post, get или put, так и операции lock, unlock или lock refresh.

findpatent.ru

Списак НТТР статус кодова — Википедија, слободна енциклопедија

Следи листа Hypertext Transfer Protocol (HTTP) одговора статус кодова. Ово укључује кодове из IETF интернет стандарда. Прва цифра статус кода одређује једну од пет класа одговора. Изрази који су коришћени су стандардни примери, мада је могуће користити и неке алтернативне изразе који су читљиви за човека. Уколико није другачије наведено, статус кодови су део HTTP/1.1 стандарда.

Мајкрософт понекад користи додатне децимале да би пружили детаљније информације али ти кодови овде нису наведени.

1xx Информациони[уреди]

Захтев примљен, процес се наставља.^[1]

Ова класа статус кодова означава привремени одговор, који се састоји само од статусне линије, и опционо хедера, а ограничен је празном линијом. Пошто HTTP/1.0 није дефинисао статус кодове облика 1хх, сервери можда неће послати никакве 1хх статус кодове клијенту осим у експерименталним условима.

100 Наставити

Ово значи да је сервер примио захтев заглавља, а да клијент треба да пошаље захтев за тело. Ако је захтев за тело велики, слање захтева на сервер када је претходни захтев већ одбијен је неефикасно. Да би се проверило да ли је сервер уредно одговорио на захтев клијента, клијент треба да прими статусни код 100 као знак да је све прошло како треба и да треба наставити са захтевима.

101 Пребацивање протокола

Ово значи да је клијент упитао сервер да замени протокол а сервер га обавештава да ће то и да уради.

102 Обрада (WebDAV; RFC 2518)

Како WebDAV захтеви могу да садрже више под-захтева који укључују операције са фајловима, то може да захтева више времена за извршавање захтева. Овај код сигнализира да је сервер примио и да обрађује захтев, али да одговор још увек није доступан. Ово штити клијента од истека времена и губитка захтева.

Ова класа статус кодова сигнализира да је клијент примио оно што је захтевао односно да је све прошло како треба.

200 OK

Стандардни одговор за успешне HTTP захтеве. Одговор зависи од методе која је коришћена за слање захтева. Код GET методе, одговор ће садржати ентитет који одговара траженом захтеву. А код POST методе одговор ће садржати ентитет који описује или садржи резултат акције.^[1]

201 Креирано

Захтев је испуњен и резултовао је стварањем новог ресурса.^[1]

202 Прихваћено

Захтев је прихваћен на обраду, али обрада још није завршена. ^[1]

203 Неауторитативне информације (почев од HTTP/1.1)

Сервер је успешно обрадио захтев, али враћа информацију која је можда из другог извора.^[1]

204 Без садржаја

Сервер је успешно обрадио захтев, али не враћа никакав садржај.^[1]

205 Ресетовање садржаја

Сервер је успешно обрадио захтев, али не враћа никакав садржај. За разлику од 204 статус кодова, овај одговор тражи од клијента да подносилац захтева ресетује садржај документа.^[1]

206 Парцијални садржај

Сервер доставља само део садржаја ресурса који је клијент захтевао. За настављање овако прекинутих преузимања користе се разни алати као wget. ^[1]

207 Мулти-статус (WebDAV; RFC 4918)

Тело поруке које је садржано у XML поруци и може да садржи број раздвојених одговора статус кодова, зависно он тога колико под-захтева је направљено.^[2]

208 Већ одговорено (WebDAV; RFC 5842)

Чланови једне DAV су већ наведене у претходном одговору на овај захтев, а нису поново укључене.

226 IM коришћен (RFC 3229)

Сервер је испунио GET захтев за ресурс а одговор је представљен у одговору за једну или више инстанци-манипулација примењених на тренутну инстанцу.^[3]

3xx Редирекција[уреди]

Клијент мора да предузме додатне мере да би се захтев извршио.^[1]

Ова класа кодова статуса указује да треба предузети неку акцију како би се захтев извршио. Та радњу може предузети кориснички агент без интеракције са корисником ако и само ако метода која се користи у другом захтеву је GET или HEAD. Кориснички агент не би смео да аутоматски извршава редирекцију више од пет пута, јер такве радње обично указују на бесконачне петље.

300 Вишеструки избор

Указује на вишеструку опцију коју клијен може да изабере. Она, за инстанцу, може бити коришћена да презентује различите формате опција за видео, листе фајлова са различитим екстензијама…^[1]

301 Трајно померен

Овај и сви будући захтеви треба да буду усмерени на дати URI.^[1]

302 Пронађен

Ово је пример индустријске праксе контрадикторних стандарда.^[1] HTTP/1.0 спецификација захтева од клијента да изврши привремена преусмеравања

303 Погледај друге (почев од HTTP/1.1)

Одговор на захтев може бити пронађен под другим URI коришћењем GET методе. Када је примљен одговор POST методом, требало би претпоставити да је сервер примио податке и преусмеравање треба извршити одвојеном GET методом.^[1]

304 Немодификовано

Показује да ресурс није модификован откако је верзија спецификована од стране захтева хедера. Ово значи да нема потребе за реемитовањем ресурса, откако клијент има претходно скинуту копију.

305 Користи прокси (почев од HTTP/1.1)

Захтевани ресуср је доступан само кроз прокси, чија је адреса прослеђена кроз одговор. Многи HTTP клијенти (као Mozilla^[4] и Internet Explorer) не рукују коректно овим одговорима кроз статусне кодове, примарно из безбедносних разлога.^{[тражи се извор]}

306 Замена проксија

Не користи се више.

307 Привремено преусмеравање (почев од HTTP/1.1)

У овом случају, захтев би требало да буде поновљен коришћењем другог URI-ја. Какогод, будући захтеви би требало да и даље користе оригинални URI. За разлику од тога како је код 302 историјски имплементиран, није дозвољено мењати методу захтева када се понавља оригинални захтев. Што би значило да за одређену инстанцу, понављање захтева мора бити обављено баш оном методом која је коришћена при првом захтеву.^[5]

308 Трајна редирекција (одобрена као експериментална RFC)^[6]

Захтев, и сви будући захтеви би требало да буду поновљени коришћењем другог URI-ја. 307 и 308 (као што је предложено) паралено понашањем 302 и 301, али не дозвољава мењање HTTP методе. Тако на пример форма за трајну редирекцију ресурса се може несметано наставити.

4xx Грешке на страни клијента[уреди]

Класа 4xx статус кодова је намењена за случајеве када се грешке јаве на страни клијента. Са изузетком одговора преко HEAD упита, када сервер треба да укључи ентитет који садржи објашњење настале грешке, небитно да ли је она трајна или привремена. Ови кодови статуса су примењиви на све методе захтева. Кориснички агенти би требало да прикажу и прикључе ентитет кориснику.

400 Лош захтев

Захтев не може бити испуњен због лоше синтаксе.^[1]

401 Неауторизован

Слично као 403 забрањен, али специјално за коришћење у случајевима кад је захтевана аутентификицаја, па није прошла или још увек није одобрена. Одговор може да укључи WWW-аутентификацију хедера који садржи изазов који је могуће применити на захтевани ресурс.

402 Плаћање обавезно

Резервисано за коришћење у будућности.^[1] Првобитна намера је била да се овај код може користити као неки вид дигиталног новца, али се то није догодило.

403 Забрањен

Упит је био валидан, али сервер одбија да одговори. На серверима где је потребна потврда идентитета, то обично значи да су акредитиви успешно идентификовани али да они још увек не одобравају клијенту приступ ресурсима.

404 Није пронађен

Тражени ресурс није пронађен али ће можда бити доступан поново у будућности.^[1]

405 Метода није дозвољена

Захтев је направљен од ресурса коришћењем метода захтева који нису подржани од стране ресурса.^[1]

406 Није прихватљиво

Захтевани ресурс је способан само за генерисање садржаја који нису прихватљиви од стране ‘Прихватљивих хедера’ послатих у захтеву.^[1]

407 Потребна идентификација проксија

Клијент мора прво да се идентификује проксијем ^[1]

408 Захтев истекао

Истекло време на серверу док је чекан захтев. Према W3 HTTP спецификацијама:Клијент није послао захтев за време које је предвиђено на серверу за чекање. Клијент може да понови захтев без модификација било кад касније.

409 Конфликт

Указује на то да захтев не може бити обрађен јер долази ко конфликта у захтеву.^[1]

410 Нестао

Указује на то да захтевани ресурс више није досупан, и неће бити доступан поново. Ово може да се користи када се ресурс обришр трајно. Добијањем кода 410 клијент не би требало да захтева ресурс поново у будућности. Клијенти као што су претраживачке машине треба да обришу овај ресурс из својих индекса.

411 Потребна дужина

Захтев није спецификовао дужину свог садржаја, што је неопходно према захтеваном ресурсу.^[1]

412 Неуспели предуслов

Сервер не подржава неки од предуслова које је захтевач ставио у захтев.^[1]

413 Захтевани ентитет превелик

Захтев је већи него што је сервер вољан или у могућности да обради.^[1]

414 Тражени URI предугачак

Обезбеђен URI је предугачак да би га сервер обрадио.^[1]

415 Неподржан тип медија

Тражени ентитет садржи тип медија који сервер или ресурс не подржава.^[1]

416 Тражени опсег није задовољив

Клијент је тражио део датотеке али сервер не може да понуди тај део.^[1]

417 Неуспело очекивање

Сервер не може да испуни захтеве од очекиваног захтева хедера.^[1]

418 Ја сам на шољици чаја (RFC 2324)

Овај код је дефинисан 1998 као једна првоаприлска шала и не очекује се да буде имплементиран на HTTP серверима.

419 Идентификација истекла

Није део HTTP стандарда, овај код указује на то да је претходно валидна идентификација истекла. Користи се као алтернатива кода 401.

420 Побољшајте вашу смиреност (Twitter)

Није део HTTP стандарда, али је враћена од стране Twitter Search и Trends API када клијент досегне одређени рејтниг.^[7]

422 Необрадиви ентитет (WebDAV; RFC 4918)

Захтев је добро формиран али је немогуће детектовати семантичке грешке.^[2]

423 Закључан (WebDAV; RFC 4918)

Ресурс ком је приступљено је закључан.^[2]

424 Неуспела зависност (WebDAV; RFC 4918)

Неуспешан захтев због неуспешности претходног захтева.^[2]

424 Неуспешна метода (WebDAV)^[8]

Указује на методу која није извршена над одређеним ресурсом у овиру њеног делокруга, јер неки део извршавања ове методе није успео па ће цела метода бити прекинута.

425 Несортирана колекција (Internet draft)

Дефинисана у драфтовима «WebDAV Advanced Collections Protocol»,^[9]

426 Потребна надоградња (RFC 2817)

Клијент може да се пребаци на други протокол као што је TLS/1.0.^[10]

428 Обавезан предуслов (RFC 6585)

Оригинални сервер захтева да захтев буде условљен. Циљ му је да спречи проблем приликом ажурирања, у случају када је трећа страна мењала нешто на серверу што је довело до сукоба.^[11]

429 Превише захтева (RFC 6585)

Корисник је послао превише захтева за одређено време.

431 Захтевана поља хедера превелика (RFC 6585)

Сервер није вољан да обради захтев због тога што су нека индивидуална поља хедера, или су сва поља хедера превелика.^[11]

444 Нема одговора (Nginx)

Коришћено у Nginx логовима да укаже на то да је сервер вратио информацију клијенту и затворио конекцију.

449 Покушајте поново са (Microsoft)

Мајкрософтова екстензија. Захтев треба да се понови након што се предузму одговарајуће радње.^[12]

Често претраживачке машине или неке апликације игноришу потребне параметре.

450 Блокирано од стране Windows родитељске контроле (Microsoft)

Мајкрософтова екстензија. Ова грешка се јавља кад је укључена Windows родитељска контрола и блокира приступ одређеној веб страници.^[13]

451 Недоступно због правних разлога (Internet draft)

Дефинисано у интернет драфту «A New HTTP Status Code for Legally-restricted Resources».^[14] Намењен да се користи када ресурс није доступан из правних разлога.

451 Редирекција (Microsoft)

Коришћена у Exchange ActiveSync ако постоји ефикаснији сервер или сервер не може да приступи поштанском сандучету корисника.^[15]

494 Захтевани хедер превелик (Nginx)

Nginx интерни код сличан са 412 али је представљен раније^{[16][оригинално истраживање?]}

497 HTTP у HTTPS (Nginx)

Nginx интерни код коришћен за HTTP захтев који је послат на HTTPS порт да би га разликовали од 4XX у логу о грешкама редирекције странице.

499 Затворен захтев од стране клијента (Nginx)

Коришћен у Nginx логовима да укаже кад конекција буде затворена од стране клијента док сервер и даље обрађује захтев, при том онемогућавајући сервер да пошаље код статуса.^[17]

5xx Грешке на страни сервера[уреди]

Сервер није успео да испуни наизглед исправан захтев.^[1]

Статусни кодови који почињу цифром 5 показују случајеве у којима је до грешке дошло на страни сервера. Осим када је у питању HEAD захтев, сервер треба да да ентитет који садржи објашњење грешке, и да да индикатор да ли је грешка трајне или тренутне природе. Исто тако, кориснички агенти треба да покажу прикључен ентитет кориснику. Ови кодови се могу применити на све методе захтевања.

500 Интерна сервер грешка

Генеричка порука о грешци, враћа се кад нема специфичнијих порука које су погодне за дату ситуацију.^[1]

501 Није имплементирана

Сервер не препознаје методу захтева, или није у стању да испуни захтев. ^[1]

502 Bad Gateway

Сервер је деловао као gateway или прокси и примио је неважећи одговор од сервера за отпремање.^[1]

503 Сервис недоступан

Сервер је тренутно недоступан (јер је преоптерећен или због одржавања).^[1] Генерално, ово је тренутно стање.

504 Gateway Timeout

Сервер је деловао као gateway или прокси и није примио на време одговор од сервера за отпремање.^[1]

505 HTTP неподржана верзија

Сервер не подржава верзију HTTP протокола који је коришћен у захтеву.^[1]

507 Недовољна меморија (WebDAV; RFC 4918)

Сервер није у могућности да сачува репрезентацију која је потребна да би се захтев извршио.^[2]

508 Детектована петља (WebDAV; RFC 5842)

Сервер је открио бесконачну петљу док је обрађивао захтев.

509 Проток лимита прекорачен (Apache bw/limited extension)

Овај код статуса, док је коришћен од стране многих сервера, није спецификован ни у једном RFCs.

510 Није продужен (RFC 2774)

Даља проширења захтева су потребна да би га сервер обрадио.^[18]

511 Потребна идентификација мреже (RFC 6585)

Клијент треба да се идентификује да би добио приступ мрежи(нпр. када се тражи сагласност са условима коришћења пре него што дамо пун приступ Интернету преко Wi-Fi hotspot-а).^[11]

Погледај још[уреди]

1. ↑ ^{1,001,011,021,031,041,051,061,071,081,091,101,111,121,131,141,151,161,171,181,191,201,211,221,231,241,251,261,271,281,291,301,311,321,33} Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol – HTTP/1.1. IETF. RFC 2616. Retrieved October 24, 2009.
2. ↑ ^{2,02,12,22,32,4} Dusseault, Lisa, ed. (June 2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF. RFC 4918. Retrieved October 24, 2009.
3. ^ Delta encoding in HTTP. IETF. January 2002. RFC 3229. Retrieved February 25, 2011.
4. ^ „Mozilla Bugzilla Bug 187996: Strange behavior on 305 redirect”. 3. 3. 2003. Приступљено 21. 5. 2009. 
5. ^ „Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”. IETF. 2012. Приступљено 8. 10. 2012. 
6. ^ „The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)”. IETF. 2012. Приступљено 27. 3. 2012. 
7. ^ „Twitter Error Codes & Responses”. Twitter. 2012. Архивирано из оригинала на датум 25. 02. 2012. Приступљено 20. 1. 2012. 
8. ^ „WebDAV Status Codes: 300s and 400s”. Microsoft Developer Network. Приступљено 9. 11. 2012. 
9. ^ Slein, Judy; Whitehead, Jim; Davis, Jim; Clemm, Geoffrey; Fay, Chuck; Crawford, Jason; Chihaya, Tyson (June 18, 1999). WebDAV Advanced Collections Protocol. IETF. I-D draft-ietf-webdav-collection-protocol-04. Retrieved October 24, 2009.
10. ^ Khare, Rohit; Lawrence, Scott (May 2000). Upgrading to TLS Within HTTP/1.1. IETF. RFC 2817. Retrieved October 24, 2009.
11. ↑ ^11,011,111,2 Nottingham, M.; Fielding, R. (април 2012). „RFC 6585 – Additional HTTP Status Codes”. Request for Comments. Internet Engineering Task Force. Приступљено 1. 5. 2012. 
12. ^ „2.2.6 449 Retry With Status Code”. Microsoft. 2009. Приступљено 26. 10. 2009. 
13. ^ „Screenshot of error page” (bmp). Приступљено 11. 10. 2009. 
14. ^ Bray, Tim (January 11, 2013). A New HTTP Status Code for Legally-restricted Resources. IETF. I-D draft-tbray-http-legally-restricted-status-02. Retrieved March 21, 2013.
15. ^ „MS-ASCMD, Section 3.1.5.2.2”. 
16. ^ „Nginx Change Log”. nginx.org/. Приступљено 9. 11. 2012. 
17. ^ Sysoev, Igor (2007). „Re: 499 error in nginx”. Приступљено 9. 12. 2010. 
18. ^ Nielsen, Henrik Frystyk; Leach, Paul J.; Lawrence, Scott (February 2000). An HTTP Extension Framework. IETF. RFC 2774. Retrieved October 24, 2009.

Спољашње везе[уреди]

sr.wikipedia.org

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

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

GET /index.html HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/4.05 (WinNT; 1)


НТТР/1.0 200 OK
Content-type: text/plain
Date: Fri, 10 Jan 1998 08:17:58 GMT
Server: Apache/1.2.6
Last-modified: Mon, 12 Jun 1997 21:53:08 GMT
Content-length: 14

Hello, world!

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

Послав запрос и заголовки, клиент может отправить дополнительные данные. Эти данные используются главным с методом POST для передачи .

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

100-199 Информационный
200-299 Запрос клиента успешен
300-399 Запрос клиента переадресован, необходимы дальнейшие действия
400-499 Запрос клиента является неполным
500-599 Ошибки сервера

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

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

LINK Связывает информацию заголовка с документом на сервере. 
UNLINK Отменяет связь информации заголовка с документом на сервере. 
PUT Помещает тело содержимого запроса по указанному URI. 
DELETE Удаляет данные, находящиеся на сервере по заданному URI. 
OPTIONS Запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.
TRACE Требует, чтобы тело содержимого запроса было возвращено без изменений. Используется для отладки.

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

GET /journal/search?month=august&date=24 HTTP/1.О

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

GET /cgi-bin/display.pl/text/doc.txt

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

POST /cgi-bin/birthday.pl HTTP/1.0
User-Agent; Mozilla/4.05 (WinNT; 1)
Host: www.ora.com
Content-type: application/x-www-form-urlencoded
Content-Length: 20

nionth=august&date=24

Метод HEAD

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

• время изменения документа;
• размер документа;
• тип документа;
• тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

WWW-Authenticate: Basic realm="WallyWorld

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ##

В реальной жизни используется тип авторизации Basic и NTLM.

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

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

GET http://www.ru/index.html HTTP/1.0

Во втором случае передается только путь к документу.

GET /index.htm HTTP/1.0

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

Host: www.example.com:8001

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

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

User-Agent: - версия пользовательской программы
Accept-Language:
Accept-Charset: Указание на предпочтительный язык документа (если документ существует на нескольких языках) и предпочтительную кодировку для текстовых документов.
Accept-Encoding: Допустимые схемы сжатия передаваемой информации.
Range: Запрос части документа, например для реализации докачки файлов.
If-Modified-Since: Запрос кэшированного документа. Позволяет получать только изменившиеся документы.

Передача данных в ответе сервера

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

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

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

GET / HTTP/1.0


HTTP/1.0 200 OK
Content-Type: text/html; charset=utf8

<html>
<body>
</body>
</html>

В типе сообщения для текстовых форматов может быть указана использованная кодировка.

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

Content-Encoding: gzip

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

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

Transfer-Encoding: chunked

А тело сообщения строится по следующим правилам

Длина куска (текстовое представление шестнадцатеричного числа)<CR><LF>
Тело куска<CR><LF>
...
0<CR><LF>

Признаком завершения передачи является кусок нулевой длины.

HTTP/1.1 200 OK
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Transfer-Encoding: chunked

4
aaaa
2
bb
0

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

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES—

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

Успешные ответы

200 OK  Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные. 

Переадресация

301 Moved Permanently   Затребованный URI перенесен на новое место (возможно на другой сайт). Новое местонахождение затребованного документа указывается в заголовке Location. 
302 Moved Temporarily   Затребованный URI перемешен, но лишь временно.
304 Not Modified    Проверка ого, что файл не менялся с запрошенной даты (заголовок lf-Modified-Since в запросе).

Логические ошибки

400 Bad Request Сервер обнаружил в запросе клиента синтаксическую ошибку. 
401 Unauthorized    Требуется пароль.
403 Forbidden       Доступ к документу запрещен
404 Not Found   Документ по указанному URI не существует. 
407 Proxy Authentication Required   Требуется пароль к proxy-серверу.

Ошибки сервера

500 Internal Server Error   При обработке запроса на один из компонентов сервера аварийно завершился. 
501 Not Implemented     Клиент запросил выполнение действия, которое сервер выполнить не может. 
504 Gateway Time-out    proxy-сервер не получил ответа от веб-сервера

parallel.uran.ru

Протоколы SLIP, PPP, HTTP и FTP WAP

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

SLIP и PPP

С протоколами SLIP (Serial Line Internet Protocol, протокол последовательного подключения к Интернету) и РРР (Point-to-Point Protocol, протокол двухточечной связи) в основном работают провайдеры, которые используют для организации доступа в Интернет выделенные телефонные линии или другие каналы.

Протоколы SLIP и РРР работают на нижних уровнях модели взаимодействия открытых систем, что позволяет специальным образом готовить пакеты данных для передачи их другими протоколами, например TCP/IP. Главное отличие протокола SLIР от протокола РРР заключается в том, что первый работает только на компьютерах с установленной операционной системой UNIX и протоколом TCP/IP, а второй используется на компьютерах, работающих под управлением системы класса Windows NT, которая умеет обращаться практически с любыми протоколами передачи данных.

HTTP

НТTР (Hyper Text Transport Protocol, гипертекстовым транспортный протокол) – протокол, предназначенный для организации пересылки данных веб-страниц по Интернету или локальной сети. За время своего существования этот протокол претерпел значительные изменения; известно несколько его версий. Особенностью протокола HTTP является то. что он может передавать любую информацию — текстовую и графическую. Это позволяет использовать при разработке веб-страниц дополнительные средства, которые делают их анимированными и красиво оформленными.

FTP

FTP (File Transfer Protocol, протокол передачи файлов) — протокол, изначально разработанный и применяемый для передачи файлов с помощью Интернета. Без этого протокола было бы невозможным скачивание из Сети музыки, фильмов И других объемных данных, без которых современный пользователь компьютера не может представить свою жизнь. Существует множество программ, которые, используя протокол FTP, позволяют скачивать значительные объемы информации даже в условиях плохого соединения и низкой скорости передачи данных.

FXP

FXP (File eXchange Protocol — протокол обмена файлами) — способ передачи файлов между двумя FTP серверами напрямую, не закачивая их на свой компьютер . При FXP сессии, клиент открывает два FTP соединения к двум разным сайтам, запрашивая пакеты данных у первого сайта как будто бы от имени второго. Польза этого метода в том, что можно перекачивать файлы по сети с огромной скоростью, обладая низкоскоростным соединением. Это свойство протокола FTP обнаружили и стали использовать ещё до появления файлообменных программ (p2p).
Несомненным преимуществом поддержки стандарта FXP является то, что на конечных пользователей, желающих скопировать файлы с одного FTP-сервера на другой, уже не действует ограничение пропускной способности их собственного интернет-соединения. Нет необходимости скачивать себе файл, чтобы потом положить его на другой FTP-сервер. Таким образом, время передачи файлов будет зависеть только от скорости соединения между двумя удаленными FTP-серверами, которая в большинстве случаев заведомо больше «пользовательской».

WAP

Аббревиатура WAP расшифровывается как Wireless Access Protocol, что можно перевести на русский примерно как “протокол беспроводного доступа”. Но подобный перевод не отображает истинного предназначения этой технологии. WAP – это протокол, с помощью которого осуществляется доступ к ресурсам глобальной сети непосредственно с сотового телефона или карманного компьютера без использования каких либо других, дополнительных устройств. Фактически, именно Wireless Access Protocol обеспечивает столь модное в последнее время понятие, как мобильный Интернет. На первый взгляд некоторым людям может показаться, что протокол WAP и не нужен. И действительно, зачем что-то придумывать, если все нужное для Интернета уже есть? К сожалению, такая точка зрения в корне ошибочна. Дело в том, что у сотовых телефонов есть ряд особенностей, из-за которых использование стандартных средств Сети практически невозможно. Во-первых, эти устройства имеют очень маленький экран. Даже у самых современных моделей он не превышает восьми строк, что, конечно же, не идет ни в какое сравнение с компьютерным дисплеем. Во-вторых, сотовые телефоны оснащаются очень медленными процессорами и очень малой по объему оперативной памятью. В принципе, для выполнения основных функций устройств этого более чем достаточно, но, опять же, если сравнивать с компьютером… В-третьих, нельзя было не учитывать очень малую пропускную способность канала, составляющую всего 9600 бит/сек (для стандарта GSM). Правда, сегодня эту проблему можно считать решенной благодаря появлению GPRS *. Ну и, наконец, четвертый момент, который нужно было обязательно учесть – низкая надежность связи, то есть возможность появления больших таймаутов. Для решения всех этих проблем и предназначен WAP. Вообще, понятно, что с помощью сотовых телефонов нельзя просматривать обычные сайты. Во-первых, они слишком объемны для этого. А во-вторых, представляете, как будет выглядеть современный сайт на восьмистрочном дисплее? Именно поэтому многие веб-проекты и обзаводятся “облегченными” wap-копиями.

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

Рекомендуем к прочтению

web-shpargalka.ru