Что значит не передан идентификатор с url. Схема работы WWW сервера. Универсальный указатель ресурса URL

URI (Uniform Resource Identifier ) - унифицированный (единообразный) идентификатор ресурса. URI - символьная строка, позволяющая идентифицировать какой-либо ресурс: документ, изображение, файл, службу, ящик электронной почты и т. д. Прежде всего, речь идёт, конечно, о ресурсах сети Интернет и Всемирной паутины. URI предоставляет простой и расширяемый способ идентификации ресурсов. Расширяемость URI означает, что уже существуют несколько схем идентификации внутри URI, и ещё больше будет создано в будущем.

Связь между URI, URL и URN

Диаграмма Венна, отображающая подмножества схемы URI: URL и URN.

URI является либо URL, либо URN, либо одновременно обоими.

• URL - это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса.
• URN - это URI, который только идентифицирует ресурс в определённом пространстве имён (соответственно, в определённом контексте), но не указывает его местонахождения. Например, URN urn:ISBN:0-395-36341-1 - это URI, который указывает на ресурс (книгу) 0-395-36341-1 в пространстве имён ISBN, но, в отличие от URL, URN не указывает на местонахождение этого ресурса: в нём не сказано, в каком магазине её можно купить или на каком сайте скачать.

Поскольку URI не всегда указывает на то, как получить ресурс, в отличие от URL, а только идентифицирует его, это даёт возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (например, личность, автомобиль, город и проч.).

История

В 1990 году в Женеве, Швейцария, в стенах Европейского совета по ядерным исследованиям британским учёным Тимом Бернерсом-Ли был изобретён определитель местонахождения ресурса URL. Так как URL является наиболее используемым подмножеством URI, то этот же 1990 год принято считать годом рождения URI. Но, строго говоря, концепция URI была документально оформлена лишь в июне 1994 года в документе RFC 1630.

Новая версия URI была определена в 1998 году в RFC 2396, тогда же слово Universal в названии было заменено на Uniform .

Недостатки

URL стал фундаментальным нововведением в Интернете, поэтому принципы URI документально закреплялись так, чтобы обеспечить полную совместимость с URL. Отсюда появился и большой недостаток URI, пришедший как наследство от URL. В URI, как и в URL, можно использовать только ограниченный набор латинских символов и знаков препинания (даже меньший, нежели в ASCII). Иными словами, если мы захотим использовать в URI символы кириллицы, или иероглифы, или, скажем, специфические символы французского языка, то нам придётся кодировать URI таким же образом, каким в Википедии кодируются URL с символами Юникода. Например, строка вида:

https://ru.wikipedia.org/wiki/Кириллица

кодируется в URL как:

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

Поскольку такому преобразованию подвергаются буквы всех алфавитов, кроме используемой в английском языке латиницы, то URI со словами на других языках (даже европейских) утрачивают способность восприниматься людьми. А это входит в грубое противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (англ. Internationalized Resource Identifier ) - международных идентификаторов ресурсов, в которых можно было бы без проблем использовать символы Юникода, и которые не ущемляли бы права других языков. Также и сам создатель URI, Тим Бернерс-Ли, говорил, что система доменных имён, лежащая в основе URL, - плохое решение, навязывающее ресурсам иерархическую архитектуру, мало подходящую для гипертекстового веба.

Структура URI

URI = [схема ":"] иерархическая- часть [ "?" запрос ] [ "#" фрагмент ]

В этой записи:

Схема

схема обращения к ресурсу (часто указывает на сетевой протокол), например, http, ftp, file, ldap, mailto, urn

Иерархическая-часть

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

Запрос

этот необязательный компонент URI описан выше.

Фрагмент

(тоже необязательный компонент)

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

Разбор структуры URI. Для так называемого «парсинга» URI (англ. parsing ), то есть для разложения URI на составные части и их последующей идентификации, удобнее всего использовать систему регулярных выражений, доступную нынче почти во всех современных языках программирования. Для разбора URI в стандарте RFC 3986 рекомендуется использовать следующий шаблон:

Этот шаблон включает в себя 9 обозначенных выше цифрами групп (подробнее о шаблонах и группах см. Регулярные выражения), которые наиболее полно и точно разбирают типичную структуру URI, где:

• группа 2 - схема,
• группа 4 - источник,
• группа 5 - путь,
• группа 7 - запрос,
• группа 9 - фрагмент.

Таким образом, если при помощи данного шаблона разобрать, например, такой типичный идентификатор URI:

http://www.ics.uci.edu/pub/ietf/uri/#Related

то 9 вышеуказанных групп шаблона дадут следующие результаты соответственно:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. нет результата
6. нет результата
7. #Related
8. Related

Примеры URI:

Абсолютные URI

• https://ru.wikipedia.org/wiki/URI
• ftp://ftp.is.co.za/rfc/rfc1808.txt
• file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
• file:///C:/file.wsdl
• file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
• ldap:///c=GB?objectClass?one
• mailto:[email protected]
• sip:[email protected]
• news:comp.infosystems.www.servers.unix
• data:text/plain;charset=iso-8859-7,%be%be%be
• tel:+1-816-555-1212
• telnet://192.0.2.16:80/
• urn:oasis:names:specification:docbook:dtd:xml:4.1.2

2) Относительные URI

• /relative/URI/with/absolute/path/to/resource.txt
• //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
• relative/path/to/resource.txt
• ../../../resource.txt
• resource.txt
• /resource.txt#frag01
• #frag01

[пустая строка] - эквивалентно разбору идентификатора парсером с результатом [пустая строка], то есть ссылка ведёт на объект по умолчанию в схеме по умолчанию

Служба DNS

DNS - система доменных имен. Доменные имена системы DNS – синонимы IP-адреса, так же, как имена в адресной книжке вашего телефона – синонимы телефонных номеров. Они символьные, а не числовые; они удобнее для запоминания и ориентации; они несут смысловую нагрузку. www.irnet.ru → таблицы DNS →193.232.70.36 Доменные имена также уникальны, т.е. нет в мире двух одинаковых доменных имён. Доменные имена, в отличие от IP-адресов необязательны, они приобретаются дополнительно.

Рис. 2. Иерархия в системе DNS.

Так же уникальны адреса, которые указываются на конвертах при доставке писем обычной почтой. В мире нет стран с одинаковыми названиями. И если названия городов иногда и повторяются, то в сочетании с делением на более крупные административные единицы типа районов и областей они становятся уникальными. А названия улиц не должны повторяться в пределах одного города. Таким образом, адрес на основе географических и административных названий однозначно определяет точку назначения. Домены имеют аналогичную иерархию. Имена доменов отделяются друг от друга точками: lingvo.yandex.ru, krkime.com.

DNS обладает следующими характеристиками:

• Распределённость администрирования . Ответственность за разные части иерархической структуры несут разные люди или организации.
• Распределённость хранения информации . Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности , и (возможно) адреса корневых DNS-серверов .
• Кеширование информации . Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура , в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование . За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

Уровни домена. Различают домены трех уровней.

Домены первого или верхнего уровня делятся на две группы:

1) Это домены с территориальной принадлежностью, например: .ru .by .ua .de .us и т. д. Т. е. это домены которые присвоены какой-то определенной стране. По ним можно, например, определить к какой стране принадлежит тот или иной сайт.

2) Вторая группа доменов первого уровня это домены, какого-то определенного назначения. Например: .com – для коммерческих организаций, .info – для информационных сайтов, .tv – для телевизионных компаний и т. д. По этим доменам можно определить определенную направленность сайта. Хотя, по правде сказать, в последнее время они все больше используются как угодно и часто не придерживаются своего назначения.

Домены первого уровня не возможно использовать в качестве адреса своего сайта. Они служат для создания доменов второго уровня , поэтому на любом из доменов первого уровня можно зарегистрировать домен второго уровня. Домен второго уровня состоит из следующих элементов: www.имя_сайта.домен первого уровня. Например: www.webmastermix.ru. Рекомендуется использовать доменные имена второго уровня для адреса сайта. Они лучше всего читаются и запоминаются людьми, а так же воспринимаются поисковыми системами. Поэтому большинство сайтов имеет доменные имена именно этого уровня.

Кроме того существуют домены третьего уровня . Они создаются на основе доменов второго уровня. Домен третьего уровня выглядит так: www.forum.webmastermix.ru. Зарегистрировав домен второго уровня вы можете самостоятельно создавать на его основе сколько угодно доменов третьего уровня. Зарегистрировать доменное имя для своего сайта вы можете при помощи специальных сервисов.

ВЕБ-ТЕХНОЛОГИИ: HTML, JAVASCRIPT

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

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

Основой всей Всемирной паутины является язык разметки гипертекста HTML – Hyper Text Markup Language (рис. 3). Он служит для логической (смысловой) разметки документа (веб-страницы). Иногда его неправомерно используют для управления способом отображения содержимого веб-страниц на экране монитора или при выводе на принтер, что в корне противоречит идеологии, принятой во всемирной паутине.

Рис. 3. Веб-технологии

Для целей управления отображением содержимого веб-страниц предназначены каскадные таблицы стилей (CSS). CSS во многом сходны со стилями, применяемыми в популярном текстовом процессоре Word.

Для придания веб-страницам динамизма (выпадающие меню, анимация) используются языки написания скриптов. Стандартным скриптовым языком во всемирной паутине является JavaScript. Ядром языка JavaScript является ECMAScript.

HTML, CSS, JavaScript – являются языками, с помощью которых можно создавать сколь угодно сложные веб-сайты. Но это всего лишь лингвистическое обеспечение, в то время как в браузерах документы представляются в виде набора объектов, множество типов которых является объектной моделью браузера (BOM). Объектная модель браузера уникальна для каждой модели и таким образом возникают проблемы при создании межбраузерных приложений. Поэтому Веб-консорциум предложил объектную модель документа (DOM), являющуюся стандартным способом представления веб-страниц с помощью набора объектов.

Синтаксис современного HTML описан с помощью расширяемого языка разметки XML – Extensible Markup Language. XML позволят создавать собственные языки разметки, аналогичные HTML в виде DTD. Существует множество таких языков: для представления математических и химических формул, знаний и т. д.

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

ЭЛЕКТРОННАЯ ПОЧТА

Электронная почта (email, e-mail, от англ. electronic mail) - технология и предоставляемые ею услуги по пересылке и получению электронных сообщений (называемых «письма» или «электронные письма») по распределённой компьютерной сети. Основным отличием от прочих систем передачи сообщений является возможность отложенной доставки и развитая система взаимодействия между независимыми почтовыми серверами.

Электронная почта даёт возможность посылать и получать сообщения, отвечать на письма корреспондентов автоматически, используя их адреса, рассылать копии письма сразу нескольким получателям, переправлять полученное письмо по другому адресу, использовать вместо адресов (числовых или доменных имен) логические имена, создавать несколько подразделов почтового ящика для разного рода корреспонденции, включать в письма текстовые файлы, пользоваться системой "отражателей почты" для ведения дискуссий с группой ваших корреспондентов и т.д. Для отправления почтового сообщения по электронной почте надо обязательно указать адрес почтового ящика. Почтовый ящик абонента электронной почты представляет собой область на жестком диске почтового сервера, отведенную для пользователя.

Развитие технологии Internet привело к появлению современных протоколов для обмена сообщениями, которые предоставляют большие возможности для обработки писем, разнообразные сервисы и удобство в работе. Так, например, протокол SMTP, работающий по принципу клиент-сервер, предназначен для отправки сообщений с компьютера к адресату. Обычно доступ к серверу SMTP не защищается паролем, так что можно использовать для отправки писем любой известный сервер в сети. В отличие от серверов для отправки писем, доступ к серверам для хранения сообщений защищается паролем. Поэтому необходимо использовать сервер или службу, в которой существует учётная запись. Эти серверы работают по протоколам POP и IMAP, которые различаются способом хранения писем.

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

Протокол IMAP удобен тем людям, которые пользуются постоянным подключением к сети. Сообщения, поступившие на адрес, также хранятся на сервере, но, в отличие от POP3, при проверке почты сначала будут загружены только заголовки сообщений. Само письмо можно будет прочитать после выбора заголовка сообщения (оно загрузиться с сервера). Ясно, что при коммутируемом соединении работа с почтой по этому протоколу приводит к неоправданным потерям времени.

Существует несколько протоколов приема передачи почты между многопользовательскими системами.

Краткое описание некоторых из них:

1) SMTP (Simple Mail Transfer Protocol) - это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP, причем передача должна быть обязательно инициирована самой передающей системой.

MTA (Mail Transfer Agent) - агент передачи почты - является основным компонентом системы передачи почты Internet, который представляет данный сетевой компьютер для сетевой системы электронной почты. Обычно пользователи работают не с MTA, а с программой MUA (Mail User Agent) - клиентом электронной почты. Схематично принцип взаимодействия показан на рисунке.

2) POP, POP2, POP3 (Post Office Protocol) - три достаточно простых невзаимозаменяемых протокола, pазpаботанные для доставки почты пользователю с центрального mail-сеpвеpа, ее удаления с него и для идентификации пользователя по имени/паролю. POP включает в себя SMTP, который используется для передачи почты, исходящей от пользователя. Почтовые сообщения могут быть получены в виде заголовков, без получения письма целиком.

После установки соединения протокол РОР3 проходит три последовательных состояния

1. Авторизация клиент проходит процедуру аутентификации
2. Транзакция клиент получает информацию о состоянии почтового ящика, принимает и удаляет почту.
3. Обновление сервер удаляет выбранные письма и закрывает соединение.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Internet Message Access Protocol) - предоставляет пользователю богатые возможности для работы с почтовыми ящиками, находящимися на центральном сервере

o IMAP осуществляет хранение почты на сеpвеpе в файловых диpектоpиях, а также предоставляет клиенту возможность производить поиск строк в почтовых сообщениях на самом сеpвеpе.

o IMAP2 - используется в редких случаях.

o IMAP3 - несовместимое ни с чем pешение, не используется.

o IMAP2bis - pасшиpение IMAP2, позволяет сеpвеpам pазбиpаться в MIME-стpуктуpе (Multipurpose Internet Mail Extensions) сообщения, используется до сих пор.

o IMAP4 - пеpеpаботанный и pасшиpенный IMAP2bis, который можно использовать где угодно.

o IMAP4rev1 - pасшиpяет IMAP большим набором функций, включая те, котоpые используются в DMSP (Distributed Mail System for Personal Computers).

4) ACAP (Application Configuration Access Protocol) - протокол, pазpаботанный для работы с IMAP4; добавляет возможность поисковой подписки и подписки на доски объявлений, почтовые ящики и используется для поиска адресных книг.

5) DMSP (или PCMAIL) - протокол для приема/отправки почты, особенность которого заключается в том, что пользователь может иметь более одной рабочей станции в своем пользовании. Рабочая станция содержит статусную информацию о почте, диpектоpию, через которую происходит обмен, которая при подключении к серверу обновляется до текущего состояния на mail-сеpвеpе.

6) MIME - стандарт, определяющий механизмы для отправки разного рода информации с помощью электронной почты, включая текст на языках, отличных от английского, для которых используются символьные кодировки, отличные от ASCII, а также 8-битный бинарный контент, такой как картинки, музыка, фильмы и программы.

Самостоятельная работа.

Выполнить приведенный в тексте пример (раздаточный материал) сохранить в собственной папке на рабочем столе.

9.2. Работа с преподавателем:

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

К концу занятия показать преподавателю отчет о выполненной работе и получить зачет по данной работе.

9.3. Контроль исходного и заключительного уровня знаний:

Тестирование на компьютере.

Похожая информация.

Для доступа к любым сетевым ресурсам необходимо знать где они размещены и как к ним можно обратиться. Во Всемирной паутине используется стандартизованная схема адресации и идентификации, учитывающую опыт адресации и идентификации e-mail, Gopher, WAIS, telnet, ftp и т.п. - URL, Uniform Resource Locator.

URI (Uniform Resource Identifier, Универсальный идентификатор ресурса) (RFC 2396, August 1998) - компактная строка символов для идентификации абстрактного или физического ресурса. Под ресурсом понимается любой объект, принадлежащий некоторому пространству. Включает и переопределяет определенные ранее URL (RFC 1738/RFC 1808) и URN (RFC 2141, RFC 2611).

URI предназначен для уникальной идентификации любого ресурса.

Некоторые подмножества URI:

URN (Uniform Resource Name, Универсальное имя ресурса) - частная URI-схема "urn:" с подмножеством "пространства имен", который должен быть уникальным и неизменным даже в том случае, когда ресурс уже не существует или недоступен.

Предполагается что, например браузер, знает, где искать этот ресурс.

Синтаксис:

urn:namespace: data1.data2,more-data, где namespace (пространство имен) определяет, каким образом используются данные, указанные после второго ":".

Пример URN:

urn:ISBN: 0-395-36341-6

ISBN - тематический классификатор для издательств

0-395-36341-6 - конкретный номер тематики книги или журнала

При получении URN клиентская программа обращается к ISBN (каталогу "тематический классификатор для издательств" в Интернете). И получает расшифровку номера тематики "0-395-36341-6" (например: "квантовая химия").

URN массово используется в P2P сетях (подобных edonkey).

Пример URN указывающего на образ диска Adobe Photoshop v8.0 в сети edonkey:

urn:ed2k://|file|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/

ed2k - указывает на сеть

Adobe Photoshop v8.0.iso - название файла

940769280 - размер в байтах

- идентификатор файла (вычисляется с помощью хеш-функции)

Универсальный указатель ресурса URL:

URL (Uniform Resource Locator, RFC 1738) - унифицированный локатор (указатель) ресурсов, стандартизированный способ записи адреса ресурса в WWW и сети Интернет. Адрес URL имеет гибкую и расширяемую структуру для максимально естественного указания местонахождения ресурсов в сети, который идентифицирует ресурс по способу доступа к нему (например, его "местонахождению в сети") вместо того, чтобы идентифицировать его по названию или другим атрибутам этого ресурса.

Примеры URL:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

Для представления адреса используется ограниченный набор символов ASCII.

Общий вид адреса можно представить так:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

схема обращения к ресурсу : http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais и т.п.

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

хост- доменное имя хоста или его IP-адрес.

Порт- порт хоста для подключения

полный-путь-к-ресурсу - уточняющая информация о месте нахождения ресурса (зависит от протокола).

Примеры URL:

http://example.com #запрос стартовой страницы по умолчанию

http://www.example.com/site/map.html #запрос заданной страницы в указанном каталоге

http://example.com:81/script.php #подключение на нестандартный порт

http://example.org/script.php?key=value #запрос с передачей параметров скрипту

ftp://user:[email protected] #подключение к ftp-серверу с авторизацией

http://192.168.0.1/example/www #подключение по сетевому адресу

file:///srv/www/htdocs/index.html #открытие локального файла

gopher://example.com/1 #подключение к серверу gopher

URL - Uniform Resource Locators явно описывает, как добраться до объекта.

Появление адресов URL стало существенным нововведением в Интернете. Однако с момента его изобретения и по сей день стандарт URL обладает серьёзным недостатком - в нём можно использовать только ограниченный набор символов, даже меньший, нежели в ASCII: латинские буквы, цифры и лишь некоторые знаки препинания- .

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

В русскоязычной Википедии ежедневно приходится видеть примеры кодирования URL, поскольку русский язык использует символы кириллицы. Например, строка вида:

http://ru.wikipedia.org/wiki/Микрокредит

кодируется в URL как:

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82

Такое преобразование происходит в два этапа: сначала каждый символ кириллицы кодируется в Юникоде (UTF-8) в последовательность из двух байтов, а затем каждый байт этой последовательности записывается в шестнадцатеричном представлении:

М → D0 и 9C → %D0%9C

и → D0 и B8 → %D0%B8

к → D0 и BA → %D0%BA

р → D1 и 80 → %D1%80, и т. д.

Перед каждым таким шестнадцатеричным кодом байта, согласно спецификации URL, ставится знак процента (%) - отсюда даже возник английский термин «percent-encoding», обозначающий способ кодирования символов в URL и URI.

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

Это всё входит в противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (International Resource Identifier) - международных идентификаторов ресурсов, в которых можно было бы без проблем использовать символы Юникода, и которые поэтому не ущемляли бы права других языков.

Другие схемы URL

Схема HTTP .

В схеме указывается ее идентификатор, адрес машины, TCP-порт, путь в директории сервера, переменные и их значения, метка.

Синтаксис:

http://[[:@][:][?]]

http - название схемы

user - имя пользователя

host - имя хоста

port - номер порта

query (<имя-поля>=<значение>{&<имя-поля>=<значение>) - строка запроса

Определен в RFC 2068. По умолчанию, port=80.

Примеры:
http://ipm.kstu.ru/internet/index.php

Это наиболее распространенный вид URI, применяемый в документах WWW. Вслед за именем схемы (http) следует путь, состоящий из доменного адреса машины и полного адреса HTML-документа в дереве сервера HTTP.

В качестве адреса машины допустимо использование и IP-адреса:

http://195.208.44.20/internet/index.php

Если сервер протокола HTTP запущен на другой, отличный от 80 порт TCP, то это отражается в адресе:

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
Символ "#" отделяет имя документа от имени метки.

Переменные и их значения передаются следующим образом:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Значения "var1" и "var2" - это имена переменных, а "value1" и "value2" - их значения.

Схема FTP

Данная схема позволяет адресовать файловые архивы FTP.

Синтаксис:

ftp://[[:@][:]

ftp - название схемы

user - имя пользователя

password - пароль пользователя

host - имя хоста

port - номер порта

url-path - путь к файлу и сам файл

Определен в RFC 1738. По умолчанию, port=21, user=anonymous, password=email-адрес, если имя указано, а пароль нет, то он запрашивается в диалоге.

имеет вид:

//...//[;type=], где :

Примеры: ftp://ipm.kstu.ru/students/name/

Чтобы указать имя пользователя и его пароль, надо записать так:
ftp://name:password@ftp://ipm.kstu.ru/students/name/

В данном случае эти параметры отделены от адреса машины символом "@", а друг от друга двоеточием.

Схема MAILTO

Данная схема предназначена для отправки почты.

Синтаксис:

mailto:[{,,...}][?]

mailto - название схемы

e-mail-1 (@)- первый адрес электронной почты

user - имя пользователя

host - имя хоста

e-mail-2 - второй адрес электронной почты

query (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - строка запроса

mailto:[email protected]

В этой схеме передаются поля и их значения:

mailto:[email protected]?subject=Тема_письма&body=Текст_который _будет_вставлен_в_письмо

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

mailto:[email protected]?subject=Тема_письма&body=Текст_который _будет_вставлен_в_письмо

Что такое HTTP?

Первый документ (но не стандарт) - RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996)

Последняя версия - RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee June 1999)

Hypertext Transfer Protocol - протокол передачи гипертекста, протокол высокого уровня (а именно, уровня приложений). Используется службой WWW для передачи Web-страниц.

HTTP (HyperText Transfer Protocol, RFC 2616, текущая версия HTTP/1.1) - протокол передачи гипертекста. Этот протокол изначально был предназначен для обмена гипертекстовыми документами, сейчас его возможности существенно расширены (в частности, добавлены функции поддержки потокового вещания).

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

HTTP - протокол прикладного уровня, но используется также в качестве «транспорта» для других прикладных протоколов, таких как SOAP, XML-RPC, WebDAV.

Протокол HTTP определяет запрос-ответный способ взаимодействия между программой-клиентом и программой-сервером в рамках технологии World Wide Web.

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

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

Помимо созданных вами вложенных папок, в которые вы вольны помещать практически любое необходимое вам содержимое, серверная директория содержит обычно еще несколько каталогов, которые следует упомянуть отдельно. Во-первых, это папка CGI-BIN, где размещаются CGI-скрипты и другие запускаемые с вашего сайта интерактивные приложения, а также несколько служебных директорий, необходимых для нормальной работы сервера. На начальном этапе на них просто не следует обращать внимания. Иногда в том же каталоге, где хранится index.html, присутствует ряд дополнительных файлов: not_found.html - документ, который отображается в случае, если http-сервер не смог найти запрашиваемый пользователем файл, forbidden.html - отображается в качестве сообщения об ошибке, если доступ к запрашиваемому документу запрещен, и, наконец, robots.txt - файл, в котором специальным образом описываются правила индексации вашего сайта поисковыми машинами.

В большинстве случаев, а особенно при публикации домашней странички на серверах, предоставляющих бесплатный хостинг, к служебным директориям и папке CGI-BIN доступ пользователям закрыт, изменение содержимого файлов not_found и forbidden.html также невозможно. Это следует учитывать, если вы планируете включить в свой ресурс какое-либо интерактивное содержимое, требующее как минимум возможности помещать файлы в одну из служебных папок. В некоторых случаях вам может быть запрещено создавать на сервере вложенные каталоги, тогда пользователю придется довольствоваться исключительно одной директорией, отведенной для ваших нужд.

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

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

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

Сообщения запроса и ответа имеют общий формат. Оба типа сообщений выглядят следующим образом: сначала идет начальная строка (start-line), затем, возможно, одно или несколько полей заголовка, называемых, также, просто заголовками, затем пустая строка (то есть строка, состоящая из символов CR и LF), указывающая конец полей заголовка, а затем, возможно, тело сообщения:

начальная строка

поле заголовка 1

поле заголовка 2

поле заголовка N

тело сообщения

Заголовки протокола HTTP

Формат начальной строки клиента и сервера различаются и будут рассмотрены ниже. Заголовки бывают четырёх видов:

Общие заголовки (general-headers), которые могут присутствовать как в запросе, так и в ответе;

Заголовки запросов (request-headers), которые могут присутствовать только в запросе;

Заголовки ответов (response-headers), которые могут присутствовать только в ответе;

Заголовки объекта (entity-headers), которые относятся к телу сообщения и описывают его содержимое.

Каждый заголовок состоит из названия, символа двоеточия ":" и значения. Наиболее важные заголовки приведены в таблице 1.

Таблица 1

Заголовки протокола HTTP

Заголовок	Назначение
Заголовки объекта
Allow	Перечисляет поддерживаемые сервером методы
Content-Encoding	Способ, которым закодировано тело сообщения, например, с целью уменьшения размера
Content-Length	Длина сообщения в байтах
Content-Type	Содержит обозначение типа содержимого ответа в MIME. В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Некоторые типы содержимого: text/html - текст в формате HTML (веб-страница); text/plain - простой текст (аналогичен "блокнотовскому"); image/jpeg - картинка в формате JPEG; image/gif - то же, в формате GIF; Также может передавать кодировку для текстовых данных. Например: charset=windows-1251 charset=koi8-rus Content-Length - длина содержимого ответа в байтах (размер файла). Last-Modified - дата и время последнего изменения документа.
ETag	Уникальный тэг ресурса на сервере, позволяющий сравнивать ресурсы
Expires	Дата и время, когда ресурс на сервере будет изменён, и его нужно получать заново
Last-Modified	Дата и время последней модификации содержимого
Заголовки ответа
Age	Число секунд, через которое нужно повторить запрос для получения нового содержимого
Location	URI ресурса, к которому нужно обратиться для получения содержимого
Retry-After	Дата и время или число секунд, через которое нужно повторить запрос, чтобы получить успешный ответ
Server	Название программного обеспечения сервера, приславшего ответ
Заголовки запроса
Accept	Список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например:Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах. Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.
Accept-Charset	Кодировки символов, в которых клиент может принимать текстовое содержимое
Accept-Encoding	Способ, которым сервер может закодировать сообщение
Host	Хост и номер порта, с которого запрашивается документ
If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since	Заголовки запроса для условного обращения к ресурсу
Range	Запрос части документа
User-Agent	Название программного обеспечения клиента- значением является "кодовое обозначение" браузера, например: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)
Общие заголовки
Connection	Connection (соединение) - может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close. close ("закрыть") - соединение закрывается после ответа на данный запрос.
Date	Дата и время формирования сообщения
Pragma	Специальные, зависящие от реализации команды, касающиеся передаваемого содержимого
Transfer-Encoding	Способ кодирования сообщения при передачи

В некоторых заголовках значением является дата и время. Они должны быть представлены в формате, описанном в RFC 1123, например:

В теле сообщения содержится собственно передаваемая информация – полезная нагрузка сообщения. Тело сообщения представляет собой последовательность октетов (байтов). Тело сообщения может быть закодировано, при этом способ кодирования указывается в заголовке объекта Content-Encoding.

Сообщение запроса от клиента к серверу состоит из строки запроса (request-line), заголовков (общих, запросов, объекта) и, возможно, тела сообщения.

Строка запроса начинается с метода, затем следует идентификатор запрашиваемого ресурса, версия протокола и завершающие символы конца строки:

<Метод> <Идентификатор> <Версия HTTP>

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

HTTP/<версия>.<подверсия>

Методы протокола HTTP

Рассмотрим основные методы протокола HTTP.

Метод OPTIONS выполняет запрос информации об опциях соединения (например, методах, типах документов, кодировках), которые поддерживает сервер для запрашиваемого ресурса. Этот метод позволяет клиенту определять опции и/или требования, связанные с ресурсом, или возможности сервера, не производя никаких действий над ресурсом и не инициируя его загрузку.

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

Если идентификатор запрашиваемого ресурса – звёздочка ("*"), то запрос OPTIONS предназначен для обращения к серверу в целом.

Если идентификатор запрашиваемого ресурса – не звездочка, то запрос OPTIONS применяется к опциям, которые доступны при соединении с указанным ресурсом.

Метод GET позволяет получать любую информацию, связанную с запрашиваемым ресурсом. В большинстве случаев, если идентификатор запрашиваемого ресурса указывает на документ (например, текстовый документ, графическое изображение, видеоролик), то сервер возвращает содержимое этого документа (содержимое файла). Если запрашиваемый ресурс является приложением (программой), формирующим данные, то в теле сообщения ответа возвращаются сформированные данные, а не двоичный образ выполняемого файла. Это используется, например, при создании приложений CGI. Если идентификатор запрашиваемого ресурса указывает на директорию (каталог, папку), то, в зависимости от настроек сервера, может быть возвращено либо содержимое директории (список файлов), либо содержимое одного из файлов, находящегося в этой директории (как правило, index.html или Default.htm). В последнем случае имя папки может указываться как с символом "/" на конце, так без него. При отсутствии на конце идентификатора данного символа сервер выдаёт один из ответов с перенаправлением (с кодами статуса 301 или 302).

Различается "условный GET" ("conditional GET"), при котором сообщение запроса включает заголовки запроса If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Условный метод GET запрашивает передачу объекта, только если он удовлетворяет условиям, описанным в приведённых заголовках. Условный метод GET предназначен для уменьшения ненужной загрузки сети, поскольку позволяет не загружать вторично уже сохранённые клиентом данные.

Различается также "частичный GET" ("partial GET"), при котором сообщение запроса включает заголовок запроса Range. Частичный GET запрашивает передачу только части объекта. Частичный метод GET предназначен для уменьшения ненужной загрузки сети, за счёт запроса только части объекта, когда другая часть уже загружена клиентом. Значением заголовка Range является диапазон байтов, которые необходимо получить. Байты нумеруются с 0. Начальный и конечный байты диапазона разделяются символом "–". Если нужно получить несколько диапазонов, то они перечисляются через запятую.

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

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

Аннотация существующих ресурсов;

Регистрация сообщения на электронной доске объявлений (BBS), в конференциях новостей (newsgroups), списках рассылки (mailing lists) или подобной группе статей;

Передача блока данных, например результат ввода в форме, процессу обработки;

Выполнение запросов к базам данных (БД);

Фактически функция, выполняемая методом POST, определяется приложением, на которое указывает идентификатор запрашиваемого ресурса. Наряду с методом GET, метод POST используется при создании приложений CGI. Браузер может формировать запросы с методом POST при отправке форм. Для этого элемент FORM документа HTML, содержащего форму, должен иметь атрибут METHOD со значением POST.

Действие, выполняемое методом POST, может выполнить действие на сервере и не передать никакого содержимого в качестве результата работы. В этом случае, в зависимости от того, включает ответ тело сообщения, описывающее результат, или нет, код состояния в ответе может быть как 200 (OK), так и 204 (Нет содержимого, No Content).

Если ресурс на сервере был создан, ответ содержит код состояния 201 (Создан, Created) и включает заголовок ответа Location.

Тело сообщения, которое передаётся в запросе с методом PUT, сохраняется на сервере, причём идентификатор запрашиваемого ресурса будет идентификатором сохранённого документа. Если идентификатор запрашиваемого ресурса указывает на уже существующий ресурс, то включённый в тело сообщения объект рассматривается как модифицированная версия ресурса, находящегося на сервере. Если новый ресурс создан, то сервер сообщает пользовательскому агенту об этом посредством ответа с кодом состояния 201 (Создан, Created).

Фундаментальное различие между методами POST и PUT заключается в различном значении идентификатора запрашиваемого ресурса. URI в запросе POST идентифицирует ресурс, который обрабатывает включенный в тело сообщения объект. Этим ресурсом может быть приложение, принимающее данные. Напротив, URI в запросе PUT идентифицирует объект, включенный в запрос в виде тела сообщения, то есть пользовательский агент назначает данный URI включенному ресурсу.

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

Метод TRACE используется для возврата переданного запроса на уровне протокола HTTP. Получатель запроса (сервер Web) отправляет полученное сообщение обратно клиенту как тело объекта ответа с кодом состояния 200 (OK). Запрос TRACE не должен содержать тела сообщения.

TRACE позволяет клиенту видеть, что получает на другом конце сервер и использовать эти данные для тестирования или диагностики.

Если запрос успешно выполнен, то ответ содержит всё сообщение запроса в теле сообщения ответа, а заголовок объекта Content-Type имеет значение "message/http".

Коды ответов

После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP ответа.

Первая строка ответа – это строка состояния (Status-Line). Она состоит из версии протокола, числового кода состояния, поясняющей фразы, разделенных пробелами и завершающих символов конца строки:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Версия протокола имеет то же значение, что и в запросе.

Элемент код состояния (Status-Code) - это целочисленный трехразрядный (трёхзначный) код результата понимания и удовлетворения запроса. Поясняющая фраза (Reason-Phrase) представляет собой короткое текстовое описание кода состояния. Код состояния предназначен для обработки программным обеспечением, а поясняющая фраза предназначена для пользователей.

Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры:

1xx: Информационные коды - запрос получен, продолжается обработка.

2xx: Успешные коды - действие было успешно получено, понято и обработано.

3xx: Коды перенаправления - для выполнения запроса должны быть предприняты дальнейшие действия.

4xx: Коды ошибок клиента - запрос имеет ошибку синтаксиса или не может быть выполнен.

5xx: Коды ошибок сервера - сервер не в состоянии выполнить допустимый запрос.

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

Таблица 2

Коды ответов сервера HTTP

Код	Поясняющая фраза согласно RFC 2068	Эквивалентная поясняющая фраза на русском языке
1xx: Информационные коды
	Continue	Продолжать
2xx: Успешные коды
	OK	OK
	Created	Создан
	No Content	Нет содержимого
	Reset Content	Сбросить содержимое
	Partial Content	Частичное содержимое
3xx: Коды перенаправления
	Moved Temporarily	Временно перемещен
	Not Modified	Не модифицирован
4xx: Коды ошибок клиента
	Bad Request	Испорченный Запрос
	Unauthorized	Несанкционированно
	Not Found	Не найден
	Method Not Allowed	Метод не дозволен
	Request Timeout	Истекло время ожидания запроса
	Conflict	Конфликт
	Length Required	Требуется длина
	Request Entity Too Large	Объект запроса слишком большой
5xx: Коды ошибок сервера
	Internal Server Error	Внутренняя ошибка сервера
	Not Implemented	Не реализовано
	Service Unavailable	Сервис недоступен
	HTTP Version Not Supported	Не поддерживаемая версия HTTP

За строкой состояния следуют заголовки (общие, ответа и объекта) и, возможно, тело сообщения.

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

Рассмотрим простейший пример HTTP - запроса. Если в адресном окне браузера мы наберем адрес http://yandex.ru, то браузер определит IP адрес сервера yandex.ru и пошлет ему на 80-й порт такой HTTP запрос:

GET http://yandex.ru/ HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Accept-Language: ru

Cookie: yandexuid=2464977781018373381

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Host: yandex.ru

Referer: narod.ru

Proxy-Connection: Keep-Alive

Запрос передается в незашифрованном текстовом виде. Самая главная часть запроса расположена в первой строке: Это тип запроса (GET), URL адрес запрашиваемого документа(http://yandex.ru) и версия HTTP протокола (HTTP/1.0). Далее перечисляются параметры запроса. Каждая строка соответствует одному параметру. В начале строки идет имя параметра, затем двоеточие и значение параметра.

Accept - тип данных, которые может принять браузер (в кодировке MIME).

Accept-Language - предпочтительный язык, на котором браузер хочет принять данные. User-Agent - тип программы, которая отослала запрос.

Host – DNS (или IP) имя хоста, которому адресован запрос.

Cookie - кукисы (данные, которые были сохранены сервером на локальном диске клиента, при посещении данного хоста прошлый раз).

Referer - хост, со страницы которого мы отсылаем запрос. Так, например, если мы находимся на странице http://narod.ru, и нажимаем там ссылкуhttp://yandex.ru, то запрос будут отправлен хосту yandex.ru, а поле запроса referer будет содержать имя хоста narod.ru.

Набор параметров запроса не фиксирован. Помимо приведенных, могут присутствовать и другие параметры.

Наиболее интересны такие параметры, как referer и cookie. Эти параметры используются, в основном, для идентификации пользователя сервером.

Запрос GET может содержать данные, передаваемые клиентом серверу. Они передаются непосредственно через URL адрес по CGI протоколу. Данные отделены от URL знаком “?” и соединяются знаком “&”:

GET ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

Такой тип передачи данных серверу удобен, однако имеет ограничения на объем. Слишком большие массивы данных передавать через URL нельзя. Для таких целей существует другой тип зпросов: запрос POST. Запрос POST очень похож на GET, с той лишь разницей, что данные в запросе POST передаются отдельно от самого заголовка запроса:

Тело запроса должно отделяться от заголовка пустой строкой. Если сервер встречает пустую строку в POST запросе, то все что идет далее он считает телом запроса (передаваемыми данными). Отметим следующее: формат даных в теле POST запроса произволен. Несмотря на то, что чаще всего применяется CGI формат, он не обязателен. Кроме того, POST запрос не требует наличия тела запроса, и может передавать данные также и через URL.

Помимо CGI формата, иногда для передачи больших объемов информации (например файлов) применяют т.н. multipart формат (формат передаваемых данных определяется параметром Content-Type):

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

Если вы используете Firefox, вы можете воспользоваться его веб-консолью. Она отображает заголовки запросов и содержимое передаваемых файлов cookies. Для ее запуска раскройте меню браузера, щелкните по пункту «Веб-разработка» и выберите «Веб-консоль». В появившейся панели активируйте кнопку «Сеть». Введите в поле фильтра название метода – post. В зависимости от ваших целей, нажмите на кнопку формы отправляющей нужный запрос или обновите страницу. В консоли отобразится отправленный запрос. Кликните по нему мышкой, чтобы посмотреть подробнее.

Браузер Google Chrome имеет мощные инструменты отладки. Чтобы ими воспользоваться, кликните по иконке с изображением гаечного ключа, а затем раскройте пункт «Настройка и управление Google Chrome». Выберите пункт «Инструменты» и запустите «Инструменты разработчиков». В панели инструментов выберите вкладку Network и отправьте запрос. Найдите нужный запрос в списке и кликните по нему, чтобы изучить подробности.

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

Internet Explorer 9 содержит комплект под названием «Средства разработчика F12», предоставляющие подробную информацию по выполненным запросам. Они запускаются нажатием кнопки F12 или с помощью меню «Сервис», содержащее одноименный пункт. Чтобы посмотреть запрос, перейдите на вкладку «Сеть». Найдите заданный запрос в сводке и с помощью двойного клика раскройте подробную информацию.

Браузеры Chrome и Internet Explorer 9 содержат встроенные инструменты, позволяющие изучить отправленный запрос post во всех деталях. Для получения полной информации используйте их или Firefox с установленным плагином Firebug. Он очень удобен для частого изучения запросов, например, при отладке сайтов.

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

Работа с URI

Каждый день мы используем универсальные идентификаторы ресурса (Uniform Resource Identifiers, URI) , когда что-то ищем в WWW. URI нужны, чтобы идентифицировать и запросить новый вид ресурса. Используя URI, можно обращаться не только к Web-страницам, но и к FTP-серверу, Web-сервису и локальным файлам.

Вместо URI часто используется термин унифицированный указатель ресурса (Uniform Resource Locator, URL) . URI-общий термин, используемый для ссылок на ресурсы. URL - это URI, связанный с такими популярными схемами URI, как http, ftp и mailto. В технической документации термин URL больше не употребляется.

Еще один термин может быть вам уже известен - унифицированное имя ресурса (Uniform Resource Name, URN) . URN - это стандартизированный URI, используемый для указания ресурса независимо от его расположения в сети.

Проанализируем части URI, ссылающегося на страницу Web-сайта компании Global Knowledge:

http://www.globalknowledge.net:80/training/generic.asp?pageid=1078&country=DACH

Первая часть URI называется схемой (scheme) . Схема определяет пространство имен URI и может сузить синтаксис следующего за схемой выражения. Многие схемы названы по соответствующим протоколам (как http, ftp), которые они используют, но это не является обязательным. В нашем примере идентификатором схемы является http. Ограничитель схемы (// в этом примере) отделяет схему от остальной части URL.

После ограничителя схемы следует имя сервера или IP-адрес в десятичной записи с точками, например www.globalknowledge.net.

За именем сервера или IP-адресом находится номер порта, определяющий соединение с конкретным приложением на сервере. Если номер порта не задан, используется номер порта, устанавливаемый для этого протокола по умолчанию (например, порт 80 для HTTP).

Путь определяет страницу (и каталог) запрошенного ресурса. Он необязательно представляет физический файл на сервере, а может создаваться динамически. В данном случае путь имеет вид /training/generic.asp.

От пути символом? отделена последняя часть этого URI, называемая запросом (query) . В нашем примере запрос определен строкой pageid=1078&country=DACH. Строка запроса может состоять из нескольких компонентов, каждый из которых задает переменную и значение, объединенные символом &. Несколько компонентов запроса могут комбинироваться символом &. Так, в нашем примере первый компонент - pageid=1078 с переменной pageid и значением 1078, а второй компонент - country=DACH.

Разделы внутри ресурса можно отождествить с фрагментами. Фрагменты используются для ссылок на разделы внутри HTML-страницы. В разработке Web-страниц фрагменты также называются закладками (bookmarks). Символ # отделяет идентификатор фрагмента от пути. В URL http;//www.microsoft.com/net/basics/glossary.asp#NETFramework фрагментом является строка #NETFramework.

Если символ # добавлен в строку запроса, то это уже не фрагмент. В URL может присутствовать строка запроса или фрагмент, но не то и другое одновременно.

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

; / ? : @ & = + $ ,

Класс Uri из пространства имен System инкапсулирует универсальный идентификатор ресурсов. Он содержит свойства и методы для анализа, сравнения и комбинирования URI.

Можно создать объект Uri, передав конструктору строку URI:

Uri baseURI = new Uri("http://сайт");

Если уже есть базовый объект Uri, можно создать новый URI, комбинируя базовый URI с относительным URI:

Uri baseURI = new Uri("http://сайт"); Uri newURI = new Uri(baseURI, "my/csharp/web/level2/2_2.php");

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

В классе Uri есть несколько статических полей только для чтения, позволяющих получить некоторые широко распространенные схемы:

Uri.UriSchemeFile

Файловая схема используется для доступа к файлам локально или на совместно используемых сетевых ресурсах, для которых могут применяться имена, соответствующие соглашению об универсальном назначении имен (Universal Naming Convention, UNC ).

Uri.UriSChemeFtp

Протокол FTP со схемой ftp используется для получения файлов с ftp-сервера и, напротив, помещения файлов на ftp-сервер.

Uri.UriSchemeGopher

Протокол gopher был предшественником HTTP. Он предоставлял возможности иерархического просмотра текстовой информации о содержании, в чем превосходил FTP. Но скоро был заменен протоколом HTTP.

Uri.UriSchemeHttp, Uri.UriSchemeHttps

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

Uri.UriSchemeMailto

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

Uri.UriSchemeNews, Uri.UriSchemeNntp

Схемы news и nntp применяются в группах новостей, использующих протокол NNTP.

В классе Uri есть статические методы для проверки правильности схемы и имени хоста: Uri.CheckSchemeName() возвращает true, если имя схемы задано правильно, а метод UriCheckHostName() не только проверяет имя хоста, но и возвращает значение перечисления UriHostNameType, указывающее тип хоста.

В классе Uri имеется масса свойств с доступом только на чтение, позволяющих обращаться ко всем частям URI. В следующей таблице используем приведенный выше URI как пример, демонстрирующий применение свойств:

AbsoluteUri	Это свойство показывает полный URI. Если указанный номер порта для протокола равен номеру порта по умолчанию, конструктор Uri автоматически его удаляет. Для нашего примера значение свойства AbsoluteUri выглядит так: http://www.globalknowledge.net/t raining/generic.asp?pageid=1078&country=DACH . Если конструктору класса Uri передается имя файла, свойство AbsoluteUri автоматически помещает перед именем файла схему file://.
Scheme	Схема - первая часть URI, и в данном случае это свойство возвращает значение http.
Host	Свойство Host показывает имя хоста из URI: www.globalknowledge.net
Authority	Если номер порта равен номеру, используемому протоколом по умолчанию, свойство Authority показывает ту же строку, что и свойство Host. Если используется другой номер порта, то свойство Authority также показывает номер порта.
HostNameType	Тип имени хоста зависит от используемого имени. В данном случае получается то же самое значение перечисления UriHostNameType, которое было рассмотрено выше.
Port	С помощью свойства Port получается номер порта - 80.
AbsolutePath	Абсолютный путь начинается после номера порта в URI и заканчивается перед строкой запроса. В этом случае он имеет значение /training/generic.asp.
LocalPath	Локальный путь дает значение /training/generic.asp. Как можно видеть, для запроса HTTP между AbsolutePath и LocalPath нет никакого различия. Различие появляется, если URI ссылается на совместно используемый сетевой ресурс. Для URI в виде file:\\server\share\directory\file.txt свойство LocalPath возвращает только имена directory и file, а свойство AbsolutePath включает имена server и share.
Query	Свойство Query показывает строку, следующую после пути: ?pageid=1078&country=DACH.
PathAndQuery	Свойство PathAndQuery дает комбинацию пути и строки запроса: /training/generic.asp?pageid=1078&country=DACH.
Fragment	Если после пути следует фрагмент, он возвращается в свойстве Fragment. За путем могут следовать только строка запроса или фрагмент. Фрагмент идентифицируется символом #
Segments	Свойство Segments возвращает массив строк, сформированный из пути. В данном случае у нас есть три сегмента: /, training/ и generic.asp.
UserInfo	Установленное в URI имя пользователя можно прочитать из свойства UserInfo. Передача имен пользователей распространена в протоколе FTP, и если указан не анонимный пользователь, например ftp://[email protected], то свойство UserInfo вернет myuser.

Кроме перечисленных, существует еще несколько свойств, возвращающих булевы значения, если URI представляет файл, путь UNC, адрес обратной связи или если для данного протокола используется номер порта по умолчанию. Это свойства IsFile, IsUnc, IsLoopback и IsDefaultPort соответственно.

1.4. Универсальный идентификатор ресурса URI

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

Многие виды ресурсов, размещенных в Интернете, независимо от того, являются ли они HTML?документами, рисунками или файлами архива, чаще всего представляют собой файлы на жестком диске компьютера (сервера), подключенного к сети. С каждым ресурсом сопоставляется значение, по которому можно однозначно определить его расположение, – универсальный идентификатор ресурса или URI (Universal Resource Identifier). URI широко используются как при самостоятельном доступе пользователя к ресурсу (когда, например, пользователь сам вводит URI в адресной строке браузера), так и при переходе между веб?страницами. URI также используются в HTML?документе для указания браузеру, где искать ресурсы (например, рисунки), используемые в самом документе.

Примечание

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

Идентификатор ресурса URI состоит из трех частей: из наименования механизма доступа к ресурсу, доменного имени компьютера и пути файла ресурса. Для пояснения сказанного можно рассмотреть пример:

Здесь можно увидеть, что для доступа к ресурсу, которым в данном случае является HTML?документ, используется протокол HTTP (Hyper Text Transfer Protocol). Ресурс хранится на компьютере, имеющем доменное имя somesite.com в файле ex_1.html, расположенном в папке /info/examples.

При помощи URI можно также ссылаться на части HTML?документов, например:

При использовании этого URI можно получить доступ к части HTML?документа, имеющей имя description (то, как создавать имена для фрагментов HTML?документов, будет рассмотрено в гл. 5).

URI также позволяют ссылаться на ресурсы в пределах одного компьютера. При этом указывается относительный путь ресурса. Например, чтобы из HTML?документа, расположенного в папке /info/examples, сослаться на файл /info/files/file1.jpg, достаточно задать URI /files/file1.jpg. В HTML?документах при помощи подобных ссылок указываются пути рисунков и других объектов, используемых в документах, но непосредственно не хранимых в них.

В общем случае URI считаются нечувствительными к регистру символов. Однако для полной уверенности в правильности интерпретации URI все же обращайте внимание на регистр символов в URI гиперссылок, рисунков и т. д. Это полезно для устранения таких ситуаций, когда, например, при работе сайта на компьютере под Windows все гиперссылки работают, а при помещении сайта на UNIX?сервер работать отказываются (в UNIX имена файлов чувствительны к регистру).

Универсальный Идентификатор Ресурса URI. URI известны под многими именами WWW адреса, Универсальные Идентификаторы Документов, Универсальные Идентификаторы Ресурсов URI , и, в заключение, как комбинация Единообразных Идентификаторов Ресурсов Uniform Resource Locators, URL и Единообразных Имен Ресурсов Uniform Resource Names, URN . HTTP определяет URL просто как строку определенного формата, которая идентифицирует ресурс посредством имени, расположения, или любой другой характеристики. 3.2.1 Общий синтаксис. URI в HTTP могут представляться в абсолютной форме absolute URI или относительно некоторого известного основного URI relative URI , в зависимости от контекста их использования. Эти две формы различаются тем, что абсолютные URI всегда начинаются с имени схемы с двоеточием.

URI absoluteURI relativeURI fragment absoluteURI scheme uchar reserved relativeURI net path abs path rel path net path net loc abs path abs path rel path rel path path params ? query path fsegment segment fsegment 1 pchar segment pchar params param param param pchar scheme 1 ALPHA DIGIT net loc pchar ? query uchar reserved fragment uchar reserved pchar uchar uchar unreserved escape unreserved ALPHA DIGIT safe extra national escape HEX HEX reserved ? extra safe unsafe CTL SP national любой OCTET за исключением ALPHA, DIGIT, reserved, extra, safe, и unsafe октетов Полная информация о синтаксисе и семантике URL содержится в RFC 1738 и RFC 1808. Нормальная запись Бекуса-Наура включает национальные символы, недозволенные в правильных URL, определеных RFC 1738, так как HTTP серверы позволяют использовать для представления части rel path адресов набор не зарезервированных символов, и, следовательно, HTTP прокси-сервера могут получать запросы URI, не удовлетворяющие RFC 1738. Протокол HTTP не накладывает никаких ограничений на длины URI. Серверы должны обрабатывать URI любого ресурса, любой длинны, который они обслуживают, и им надлежит обрабатывать URI неограниченной длины, если они обслуживают сервера, основанные на методе GET, которые могут создавать такой URI. Серверу следует возвращать код состояния 414 URI запроса слишком длинный, Request-URI Too Long, если URI длиннее, чем сервер в состоянии обработать.

Серверы должны обращать внимание на URI, которые имеют длину более 255 байтов, потому что некоторые старые клиенты или прокси-сервера могут неправильно поддерживать эти длины. 3.2.2 HTTP URL. Http схема используется для доступа к сетевым ресурсам при помощи протокола HTTP. Этот раздел определяет схемо-определенный синтаксис и семантику для HTTP URL. http URL http host port abs path host допустимое доменное имя машины или IP адрес в точечно десятичной форме, как определено в разделе 2.1 RFC 1123 port DIGIT Если порт пуст или не задан - используется порт 80. Это означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса - abs path. Использования IP адресов в URL следует избегать, насколько это возможно RFC 1900 . Если abs path не представлен в URL, он должен рассматриваться как при вычислении запрашиваемого URI Request-URI ресурса. 3.2.3

Конец работы -

Эта тема принадлежит разделу:

Протокол HTTP 1.1

По определению RFC 1945 HTTP 1.0 был улучшением этого протокола, допускал MIME-подобный формат сообщений, содержащий метаинформацию о передаваемых.. Однако HTTP 1.0 недостаточно учитывал особенности работы с иерархическими.. Список RFC относящийся к рассмотренным в данной работе вопросам, приведен в разделе Библиографический список. 1.1..

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

Что будем делать с полученным материалом:

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

Твитнуть

Все темы данного раздела:

Терминология
Терминология. Соединение connection. Виртуальный канал транспортого уровня, установленный между двумя программами с целью связи Сообщение message. Основной модуль HTTP связи, состоящей из структурн

Параметры протокола
Параметры протокола. Версия HTTP.HTTP использует схему нумерации типа major . minor, для указания версии протокола. Стратегия версификации протокола предназначена для того, чтобы позволить отправит

Сравнение UR
Сравнение UR. I.При сравнении двух URI, чтобы решить соответствуют ли они друг другу или нет, клиенту следует использовать чувствительное к регистру пооктетное octet-by-octet сравнение этих URI, со

Полная дата
Полная дата. HTTP приложения исторически допускали три различных формата для представления даты времени Sun, 06 Nov 1994 08 49 37 GMT RFC 822, дополненный в RFC 1123 Sunday, 06-Nov-94 08 49 37 GMT

Кодовые таблицы character sets
Кодовые таблицы character sets. HTTP использует то же самое определение термина кодовая таблица, которое определено для MIME Термин кодовая таблица используется, чтобы сослаться на метод, использую

Кодирования содержимого content codings
Кодирования содержимого content codings. Значение кодирования содержимого указывает какое преобразование кодирования было или будет применено к объекту. Кодирование содержимого используется

Кодирования передачи Transfer Codings
Кодирования передачи Transfer Codings. Значения кодирования передачи используются для указания преобразования кодирования, которое было или должно быть применено к телу объекта entity-body в целях

Медиатипы Media Types
Медиатипы Media Types. HTTP использует МедиаТипы Интернета Internet Media Types в полях заголовка Content-Type и Accept для обеспечения открытой и расширяемой типизации данных и типов. media-type t

Канонизация и предопределенные значения типа text
Канонизация и предопределенные значения типа text. Медиатипы Интернет зарегистрированы в канонической форме. В общем случае тело объекта, передаваемое HTTP сообщением, должно быть представле

Типы Multipart
Типы Multipart. MIME предусматривает ряд типов multipart - формирующих пакет из одного или нескольких объектов внутри тела одного сообщения. Все типы mulptipart используют общий синтаксис, о

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

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

Метки языков Language Tags
Метки языков Language Tags. Метка языка идентифицирует естественный язык разговорный, письменный, или другой используемый людьми для обмена информацмей с другими людьми. Машинные языки являю

Метки объектов Entity Tags
Метки объектов Entity Tags. Метки объектов используются для сравнения двух или более объектов одного и того же запрошенного ресурса. HTTP 1.1 использует метки объектов в полях заголовка ETag

Единицы измерения диапазонов Range Units
Единицы измерения диапазонов Range Units. HTTP 1.1 позволяет клиенту запрашивать только часть объекта. HTTP 1.1 использует еденицы измерения диапазонов в полях заголовка Range и Content-Rang

Типы сообщений
Типы сообщений. HTTP сообщения делятся на запросы клиента серверу и ответы сервера клиенту. HTTP-message Request Response сообщения HTTP 1.1 Сообщения запроса и ответа используют обобщенный формат

Заголовки сообщений
Заголовки сообщений. Поля заголовков HTTP, которые включают поля общих заголовков general-header, заголовков запроса request-header, заголовков ответа response-header, и заголовков объекта entity-h

Тело cообщения
Тело cообщения. Тело HTTP сообщения message-body, если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения message-body отличается от тела об

Длина сообщения
Длина сообщения. Когда тело сообщения message-body присутствует в сообщении, длина этого тела определяется одним из следующих методов в порядке старшинства 1. Любое сообщение ответа, которое не дол

Метод Method
Метод Method. Лексема метода указывает метод, который нужно применить к ресурсу, идентифицированному запрашиваемым URI Request-URI . Метод чувствителен к регистру. Method OPTIONS GET HEAD PO

Код состояния и поясняющая фраза
Код состояния и поясняющая фраза. Элемент код состояния Status-Code - это целочисленный трехразрядный код результата попытки понять и выполнить запрос. Эти коды полностью определены в раздел

Постоянные соединения Persistent Connections
Постоянные соединения Persistent Connections. Цель. До введения в протокол постоянных соединений для запроса каждого URL устанавливалось отдельное TCP соединение, что увеличивало нагрузку на HTTP с

Обсуждение Negotiation
Обсуждение Negotiation. HTTP 1.1 сервер в праве считать, что HTTP 1.1 клиент не поддерживает постоянное соединение, если посланный в запросе заголовок Connection содержит лексему соединения connect

Конвейерная обработка Pipelining
Конвейерная обработка Pipelining. Клиент, который поддерживает постоянные соединения умеет производить конвейерную обработку запросов то есть посылать несколько запросов не ожидая ответа на каждый

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

Требования к передаче сообщений
Требования к передаче сообщений. Общие требования - HTTP 1.1 серверам следует поддерживать постоянные соединения и использовать механизмы управления потоком данных TCP в целях уменьшения временных

Безопасные методы
Безопасные методы. Программистам следует понимать, что программное обеспечение при взаимодействии с Интернетом представляет пользователя, и программе следует информировать пользователя о любых дейс

Определение кодов состояния
Определение кодов состояния. Каждый код состояния, описанный ниже, включает описание метода или методов, за которым он может следовать и метаинформацию, требуемую в ответе. 10.1 1xx - Информ

Установление подлинности доступа Access Authentication
Установление подлинности доступа Access Authentication. Для установления подлинности доступа HTTP предоставляет простой механизм вызовов-ответов challenge-response, который может использоваться сер

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

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

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

Механизмы управления кэшем Cache-control Mechanisms
Механизмы управления кэшем Cache-control Mechanisms. Основные механизмы кэша в HTTP 1.1 указанные сервером время устаревания expiration time и указатель достоверности validator - неявные директивы

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

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

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

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

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

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

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

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