RFC 1738 | Унифицированные Указатели Ресурсов

Статус этого меморандума (Декабрь 1994 года)

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

Резюме

Этот документ определяет Унифицированный Указатель Ресурсов (URL), синтаксис и семантику формализованной информации для определения местоположения и доступа к ресурсам через Интернет.

1. Введение

Этот документ описывает синтаксис и семантику компактного строкового представления ресурса, доступного через Интернет. Эти строки называются «Унифицированными Указателями Ресурсов» (URL).

Спецификация основана на концепциях, введённых глобальной информационной инициативой World-Wide Web, в которой такие объекты используются с 1990 года и описаны в «Универсальных идентификаторах ресурсов в WWW», [RFC 1630 #]. Спецификация URL-адресов предназначена для удовлетворения требований, которые изложены в «Функциональных требованиях к локаторам интернет-ресурсов» [12].

Этот документ был написан рабочей группой URI Инженерной группы Интернета. Комментарии можно направлять в редакцию или в рабочую группу URI-WG <uri@bunyip.com>. Обсуждения группы заархивированы по адресу <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>.

2. Общий синтаксис URL

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

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

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

2.1 Основные части URL

Полное описание BNF синтаксиса URL приведено в Разделе 5.

В общем, URL-адреса записываются следующим образом:

<scheme>:<scheme-specific-part>

<схема>:<специфичная-часть-для-схемы>

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

Имена схем состоят из последовательности символов. Допускаются строчные буквы «a«—«z«, цифры и знаки плюс («+«), точка («.«) и дефис («—«). Для обеспечения отказоустойчивости программы, интерпретирующие URL-адреса, должны рассматривать прописные буквы как эквивалентные строчным в именах схем (например, разрешать «HTTP», а также «http»).

2.2 Проблемы с кодировкой символов URL

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

В большинстве схем URL последовательности символов в разных частях URL используются для представления последовательностей октетов, используемых в интернет-протоколах. Например, в схеме ftp имя хоста, имя каталога и имена файлов представляют собой такие последовательности октетов, представленные частями URL. В этих частях октет может быть представлен символом, который имеет этот октет в качестве своего кода в кодированном наборе символов US-ASCII [20].

Кроме того, октеты могут быть закодированы тройкой символов, состоящей из символа «%», за которым следуют две шестнадцатеричные цифры (от «0123456789ABCDEF»), образующие шестнадцатеричное значение октета. (Символы «abcdef» также могут использоваться в шестнадцатеричных кодировках.)

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

Нет соответствующего графического изображения US-ASCII:

URL-адреса записываются только графическими печатными символами из набора кодированных символов US-ASCII. Шестнадцатеричные октеты 80-FF не используются в US-ASCII, а шестнадцатеричные октеты 00—1F и 7F представляют управляющие символы; они должны быть закодированы.

Небезопасно:

Символы могут быть небезопасными по ряду причин. Символ пробела небезопасен, поскольку значительные пробелы могут исчезнуть, а незначащие пробелы могут появиться, когда URL-адреса расшифровываются, набираются или подвергаются обработке текстовыми программами. Символы «<» и «>» небезопасны, поскольку они используются в качестве разделителей URL-адресов в свободном тексте; кавычка («««) используется для разделения URL-адресов в некоторых системах. Символ «#» небезопасен и всегда должен быть закодирован, поскольку он используется во Всемирной паутине и в других системах для отделения URL-адреса от идентификаторов фрагмента/привязки, который может следовать за ним. Символ «%» небезопасен, поскольку он используется для кодирования других символов. Другие символы небезопасны, поскольку известно, что шлюзы и другие транспортные агенты иногда изменяют такие символы. Это символы «{«, «} «, «|«, «\«, «^«, «~«, «[«, «]» и «`«.

Все небезопасные символы всегда должны быть закодированы в URL-адресе. Например, символ «#» должен быть закодирован в URL-адресах даже в системах, которые обычно не имеют дело с идентификаторами фрагментов или привязок, чтобы, если URL-адрес был скопирован в другую систему, которая их использует, не было необходимости изменять кодировку URL.

Зарезервированные:

Многие схемы URL-адресов резервируют определённые символы для особого значения:

их появление в части URL-адреса, относящейся к схеме, имеет определённую семантику. Если символ, соответствующий октету, зарезервирован в схеме, этот октет должен быть закодирован. Символы «;», «/», «?», «:», «@», «=» и «&» — это символы, которые могут быть зарезервированы для специального значения в схеме. Никакие другие символы не могут быть зарезервированы в рамках схемы.

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

Таким образом, только буквенно-цифровые символы, специальные символы «$-_.+!*'(),» и зарезервированные символы, используемые для их зарезервированных целей, могут использоваться незакодированными в URL-адресе.

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

2.3 Иерархические схемы и относительные ссылки

В некоторых случаях URL-адреса используются для поиска ресурсов, содержащих указатели на другие ресурсы. В некоторых случаях эти указатели представлены в виде относительных ссылок, где выражение местоположения второго ресурса выражается в терминах «в том же месте, что и этот, но со следующим относительным путем». Относительные ссылки не описываются в этом документе. Однако использование относительных ссылок зависит от исходного URL-адреса, содержащего иерархическую структуру, на которой основана относительная ссылка.

Некоторые схемы URL (например, схемы ftp, http и file) содержат имена, которые можно считать иерархическими; компоненты иерархии разделены знаком «/».

3. Конкретные Схемы

Отображение некоторых существующих стандартных и экспериментальных протоколов описано в определении синтаксиса BNF. Далее следуют примечания по конкретным протоколам. Рассматриваемые схемы:

Схема	Описание
ftp	File Transfer protocol
http	Hypertext Transfer Protocol
gopher	The Gopher protocol
mailto	Electronic mail address
news	USENET news
nntp	USENET news using NNTP access
telnet	Reference to interactive sessions
wais	Wide Area Information Servers
file	Host-specific file names
prospero	Prospero Directory Service

Другие схемы могут быть указаны в будущих спецификациях. Раздел 4 этого документа описывает, как могут быть зарегистрированы новые схемы, и перечисляет названия некоторых схем, которые находятся в стадии разработки.

3.1 Общий синтаксис интернет-схемы

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

//<user>:<password>@<host>:<port>/<url-path>

Некоторые или все части «<user>:<password>@«, «:<password>«, «:<port>» и «/<url-path>» могут быть исключены. Данные схемы начинаются с двойной косой черты «//», чтобы указать, что они соответствуют общему синтаксису схемы Интернета. Различные компоненты подчиняются следующим правилам:

user

Необязательное имя пользователя. Некоторые схемы (например, ftp) позволяют указывать имя пользователя.

password

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

За именем пользователя (и паролем), если они есть, следует коммерческий знак «@». В поле пользователя и пароля должны быть закодированы любые «:», «@» или «/».

Обратите внимание, что пустое имя пользователя или пароль отличаются от отсутствия имени пользователя или пароля; невозможно указать пароль без указания имени пользователя. Например, <URL:ftp://@host.com/> имеет пустое имя пользователя и пароль, <URL:ftp://host.com/> не имеет имени пользователя, а <URL:ftp://foo :@host.com/> имеет имя пользователя «foo» и пустой пароль.

host

Полное доменное имя сетевого хоста или его IP-адрес в виде набора из четырёх групп десятичных цифр, разделенных знаком «.». Полные доменные имена имеют форму, описанную в Разделе 3.5 RFC 1034 [13] и Разделе 2.1 RFC 1123 [5]: последовательность меток домена, разделённых «.», каждая метка домена начинается и заканчивается буквенно-цифровым символом и возможно, также содержит символы «—». Однако самая правая метка домена никогда не будет начинаться с цифры, которая синтаксически отличает все доменные имена от IP-адресов.

port

Номер порта для подключения. Большинство схем назначают протоколы, которые имеют номер порта по умолчанию. При необходимости может быть указан другой номер порта в десятичном формате, отделённый от хоста двоеточием «:». Если порт опущен, двоеточие тоже.

url-path

Остальная часть локатора состоит из данных, специфичных для схемы, и известна как «URL-путь». Он предоставляет сведения о том, как можно получить доступ к указанному ресурсу. Обратите внимание, что «/» между хостом (или портом) и URL-адресом НЕ является частью URL-пути.

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

3.2. FTP

Схема URL-адреса FTP используется для обозначения файлов и каталогов на хостах в Интернете, доступных с использованием протокола FTP (RFC959).

URL-адрес FTP соответствует синтаксису, описанному в Разделе 3.1. Если :<port> опущен, порт по умолчанию равен 21.

3.2.1. FTP Имя и Пароль

Можно указать имя пользователя и пароль; они используются в командах ftp «USER» и «PASS» после первого подключения к FTP-серверу. Если имя пользователя или пароль не указаны, а FTP-сервер запрашивает их, следует использовать соглашения для «анонимного» FTP, а именно:

Предоставляется имя пользователя «anonymous«.
Пароль предоставляется в виде адреса электронной почты в Интернете конечного пользователя, обращающегося к ресурсу.

Если URL-адрес предоставляет имя пользователя, но не пароль, а удаленный сервер запрашивает пароль, программа, интерпретирующая URL-адрес FTP, должна запросить его у пользователя.

3.2.2. FTP URL путь

URL-путь к URL-адресу FTP имеет следующий синтаксис:

<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>

Где <cwd1> через <cwdN> и <name> являются (возможно, закодированными) строками, а <typecode> — один из символов «a«, «i» или «d«. Часть «;type=<typecode>» может быть опущена. Части <cwdx> и <name> могут быть пустыми. Весь URL-путь может быть опущен, включая «/«, отделяющий его от префикса, содержащего пользователя, пароль, хост и порт.

URL-путь интерпретируется как последовательность команд FTP следующим образом:

Каждый из элементов <cwd> должен передаваться последовательно в качестве аргумента команде CWD (изменение рабочего каталога).
Если код типа «d«, выполните команду NLST (список имен) с <name>в качестве аргумента и интерпретируйте результаты как список каталогов файлов.
В противном случае выполните команду TYPE с <typecode> в качестве аргумента, а затем получите доступ к файлу с именем <name> (например, с помощью команды RETR).

В имени или компоненте CWD символы «/» и «;» зарезервированы и должны быть закодированы. Компоненты декодируются перед их использованием в протоколе FTP. В частности, если соответствующая последовательность FTP для доступа к определенному файлу требует предоставления строки, содержащей «/», в качестве аргумента для команды CWD или RETR, необходимо кодировать каждый «/».

Например, URL-адрес <URL:ftp://myname@host.dom/%2Fetc/motd> интерпретируется FTP-интерпретацией как «host.dom», при входе в систему как «myname» (запрашивая пароль, если он запрос), а затем выполнить «CWD /etc», а затем «RETR motd». Это значение отличается от <URL:ftp://myname@host.dom/etc/motd>, который означает «CWD и т. д.», а затем «RETR motd»; начальный «CWD» может быть выполнен относительно каталога по умолчанию для «myname». С другой стороны, <URL:ftp://myname@host.dom//etc/motd> будет «CWD » с нулевым аргументом, затем «CWD и т. д.», а затем «RETR motd».

URL-адреса FTP также могут использоваться для других операций; например, можно обновить файл на удаленном файловом сервере или получить информацию о нем из списков каталогов. Механизм для этого здесь не описан.

3.2.3. FTP Typecode is Optional

Полная часть ;type=<typecode> URL-адреса FTP не является обязательной. Если он опущен, клиентская программа, интерпретирующая URL-адрес, должна угадать подходящий режим для использования. Как правило, тип содержимого файла можно определить только по имени, например, по суффиксу имени; соответствующий код типа, который будет использоваться для передачи файла, может быть затем выведен из содержимого данных файла.

3.2.4 Hierarchy

В некоторых файловых системах символ «/», используемый для обозначения иерархической структуры URL-адреса, соответствует разделителю, используемому для построения иерархии имен файлов, и, таким образом, имя файла будет выглядеть аналогично пути URL-адреса. Это НЕ означает, что URL-адрес является именем файла Unix.

3.2.5. Optimization

Клиенты, получающие доступ к ресурсам через FTP, могут использовать дополнительные эвристики для оптимизации взаимодействия. Например, для некоторых FTP-серверов может быть целесообразно держать управляющее соединение открытым при доступе к нескольким URL-адресам с одного и того же сервера. Однако для протокола FTP не существует общей иерархической модели, поэтому, если дана команда смены каталога, в общем случае невозможно сделать вывод, какая последовательность должна быть задана для перехода в другой каталог для повторного поиска, если пути разные. . Единственным надежным алгоритмом является отключение и повторное установление управляющего соединения.

3.3. HTTP

Схема URL-адреса HTTP используется для обозначения интернет-ресурсов, доступных с использованием HTTP (протокола передачи гипертекста).

Протокол HTTP указан в другом месте. Эта спецификация описывает только синтаксис URL-адресов HTTP.

URL-адрес HTTP принимает форму:

http://<host>:<port>/<path>?<searchpart>

где <host> и <port> соответствуют описанию в разделе 3.1. Если :<port> опущен, порт по умолчанию равен 80. Имя пользователя или пароль не разрешены. <path> — это селектор HTTP, а <searchpart> — это строка запроса. <path> является необязательным, как и <searchpart> и предшествующий ему «?». Если нет ни <path>, ни <searchpart>, «/» также можно опустить.

В компонентах <path> и <searchpart> «/«, «;«, «?» зарезервированы. Символ «/» может использоваться в HTTP для обозначения иерархической структуры.

3.4. GOPHER

Схема URL Gopher используется для обозначения интернет-ресурсов, доступных по протоколу Gopher.

Базовый протокол Gopher описан в RFC 1436 и поддерживает элементы и наборы элементов (каталоги). Протокол Gopher+ представляет собой набор восходящих совместимых расширений базового протокола Gopher и описан в [2]. Gopher+ поддерживает связывание произвольных наборов атрибутов и альтернативных представлений данных с элементами Gopher. URL-адреса Gopher поддерживают как элементы, так и атрибуты элементов Gopher и Gopher+.

3.4.1. Синтаксис URL-адреса Gopher

URL-адрес Gopher имеет вид:

gopher://<host>:<port>/<gopher-path>

где <gopher-path> — один из

Если :<port> опущен, порт по умолчанию равен 70. <gophertype> — это односимвольное поле для обозначения типа Gopher ресурса, на который ссылается URL-адрес. Весь <gopher-path> также может быть пустым, и в этом случае разделитель «/» также является необязательным, а <gophertype> по умолчанию равен «1».

<selector> — это строка селектора Gopher. В протоколе Gopher строки селектора Gopher представляют собой последовательность октетов, которая может содержать любые октеты, кроме 09 шестнадцатеричных (US-ASCII HT или табуляция), 0A шестнадцатеричных (символ US-ASCII LF) и 0D (символ US-ASCII CR).

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

Внутри <gopher-path> никакие символы не зарезервированы.

Обратите внимание, что некоторые строки Gopher <selector> начинаются с копии символа <gophertype>, и в этом случае этот символ будет встречаться дважды подряд. Строка селектора Gopher может быть пустой строкой; именно так клиенты Gopher обращаются к каталогу верхнего уровня на сервере Gopher.

3.4.2 Указание URL-адресов для поисковых систем Gopher

Если URL-адрес относится к поиску, который должен быть отправлен в поисковую систему Gopher, за селектором следует закодированная вкладка (%09) и строка поиска. Чтобы отправить запрос в поисковую систему Gopher, клиент Gopher отправляет строку <selector> (после декодирования), вкладку и строку поиска на сервер Gopher.

3.4.3 URL syntax for Gopher+ items

URL-адреса элементов Gopher+ имеют вторую закодированную вкладку (%09) и строку Gopher+. Обратите внимание, что в этом случае должна быть предоставлена строка %09<search>, хотя элемент <search> может быть пустой строкой.

<gopher+_string> используется для представления информации, необходимой для извлечения элемента Gopher+. Элементы Gopher+ могут иметь альтернативные представления, произвольные наборы атрибутов и могут иметь связанные с ними электронные формы.

Чтобы получить данные, связанные с URL-адресом Gopher+, клиент подключается к серверу и отправляет селектор Gopher, за которым следует вкладка и строка поиска (которая может быть пустой), за которой следует вкладка и команды Gopher+.

3.4.4 Default Gopher+ data representation

Когда сервер Gopher возвращает список каталогов клиенту, элементы Gopher+ помечаются либо знаком «+» (обозначающим элементы Gopher+), либо знаком «?» (обозначает элементы Gopher+, с которыми связана форма +ASK). URL-адрес Gopher со строкой Gopher+, состоящей только из «+», относится к представлению по умолчанию (представлению данных) элемента, в то время как строка Gopher+ содержит только «?» относится к элементу с электронной формой Gopher, связанной с ним.

3.4.5 Gopher+ items with electronic forms

Элементы Gopher+, с которыми связан +ASK (т. е. элементы Gopher+, помеченные знаком «?»), требуют от клиента извлечения атрибута +ASK элемента, чтобы получить определение формы, а затем просят пользователя заполнить форму и вернуть ответы пользователя вместе со строкой селектора для получения элемента. Клиенты Gopher+ знают, как это сделать, но зависят от «?» тег в описании предмета Gopher+, чтобы знать, когда обрабатывать этот случай. «?» используется в строке Gopher+ для согласования с использованием этого символа в протоколе Gopher+.

3.4.6 Gopher+ item attribute collections

Чтобы обратиться к атрибутам Gopher+ элемента, строка Gopher+ URL-адреса Gopher состоит из «!» или «$». «!» относится ко всем атрибутам предмета Gopher+. «$» относится ко всем атрибутам элемента для всех элементов в каталоге Gopher.

3.4.7 Referring to specific Gopher+ attributes

Чтобы сослаться на определенные атрибуты, gopher+_string URL имеет вид «!<attribute_name>» или «$<attribute_name>». Например, чтобы обратиться к атрибуту, содержащему аннотацию элемента, gopher+_string будет «!+ABSTRACT».

Для ссылки на несколько атрибутов gopher+_string состоит из имен атрибутов, разделенных закодированными пробелами. Например, «!+ABSTRACT%20+SMELL» относится к атрибутам +ABSTRACT и +SMELL элемента.

3.4.8 URL syntax for Gopher+ alternate views

Gopher+ допускает дополнительные альтернативные представления данных (альтернативные представления) элементов. Чтобы получить альтернативное представление Gopher+, клиент Gopher+ отправляет соответствующее представление и идентификатор языка (найденный в атрибуте +VIEW элемента). Для ссылки на определенное альтернативное представление Gopher+ строка URL-адреса Gopher+ должна иметь вид:

+<view_name>%20<language_name>

Например, строка Gopher+ «+application/postscript%20Es_ES» относится к альтернативному представлению постскриптума на испанском языке для элемента Gopher+.

3.4.9 URL syntax for Gopher+ electronic forms

Gopher+_string для URL-адреса, который ссылается на элемент, на который ссылается электронная форма Gopher+ (блок ASK), заполненный определенными значениями, представляет собой закодированную версию того, что клиент отправляет на сервер. Gopher+_string имеет вид:

+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A

Чтобы получить этот элемент, клиент Gopher отправляет:

<a_gopher_selector><tab>+<tab>1<cr><lf>
+-1<cr><lf>
<ask_item1_value><cr><lf>
<ask_item2_value><cr><lf>
.<cr><lf>

на сервер Гофер.

3.5. MAILTO

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

URL-адрес mailto имеет вид:

mailto:<rfc822-addr-spec>

где <rfc822-addr-spec> — это (кодировка) addr-spec, как указано в RFC 822 [6]. В URL-адресах mailto нет зарезервированных символов.

Обратите внимание, что знак процента («%») обычно используется в адресах RFC 822 и должен быть закодирован.

В отличие от многих URL-адресов, схема mailto не представляет объект данных, к которому можно получить прямой доступ; нет никакого смысла, в котором оно обозначает объект. Он используется иначе, чем тип сообщения/внешнего тела в MIME.

3.6. NEWS

Схема URL новостей используется для ссылки либо на группы новостей, либо на отдельные статьи новостей USENET, как указано в RFC 1036.

URL-адрес новостей принимает одну из двух форм:

новости: <название группы новостей>
новости: <идентификатор сообщения>

<имя группы новостей> — это иерархическое имя, разделенное точками, например, «comp.infosystems.www.misc». <message-id> соответствует Message-ID раздела 2.1.5 RFC 1036, без заключенных «<» и «>»; он принимает вид <уникальный>@<полное_имя_домена>. Идентификатор сообщения можно отличить от имени группы новостей по наличию рекламного ролика в символе «@». Никакие дополнительные символы не зарезервированы в компонентах URL-адреса новостей.

Если <имя группы новостей> равно «*» (как в <URL:news:*>), оно используется для ссылки на «все доступные группы новостей».

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

3.7. NNTP

Схема URL-адресов nntp — это альтернативный метод ссылки на новостные статьи, полезный для указания новостных статей с серверов NNTP (RFC 977).

URL-адрес nntp имеет вид:

nntp://<хост>:<порт>/<название-новости>/<номер-статьи>

где <хост> и <порт> соответствуют описанию в разделе 3.1. Если :<port> не указано, по умолчанию используется порт 119.

<имя группы новостей> — это имя группы, а <номер статьи> — числовой идентификатор статьи в этой группе новостей.

Обратите внимание, что в то время как URL-адреса nntp: определяют уникальное местоположение ресурса статьи, большинство серверов NNTP в настоящее время в Интернете настроены только на разрешение доступа от локальных клиентов, и, таким образом, URL-адреса nntp не обозначают глобально доступные ресурсы. Таким образом, в качестве способа идентификации новостных статей предпочтительнее использовать форму URL-адреса news:.

3.8. TELNET

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

URL-адрес telnet имеет вид:

telnet://<пользователь>:<пароль>@<хост>:<порт>/

как указано в разделе 3.1. Последний символ «/» может быть опущен.

Если :<port> опущен, порт по умолчанию равен 23. :<password> можно опустить, как и всю часть <user>:<password>.

Этот URL обозначает не объект данных, а скорее интерактивную службу. Удаленные интерактивные службы сильно различаются по средствам, с помощью которых они разрешают удаленный вход в систему; на практике указанные <user> и <password> носят только рекомендательный характер: клиенты, получающие доступ к URL-адресу telnet, просто сообщают пользователю предлагаемые имя пользователя и пароль.

3.9. WAIS

Схема URL WAIS используется для обозначения баз данных WAIS, поисковых запросов или отдельных документов, доступных в базе данных WAIS. WAIS описан в [7]. Протокол WAIS описан в RFC 1625 [17]; Хотя протокол WAIS основан на Z39.50-1988, схема URL-адресов WAIS не предназначена для использования с произвольными службами Z39.50.

URL-адрес WAIS принимает одну из следующих форм:

wais://<хост>:<порт>/<база данных>
wais://<хост>:<порт>/<база данных>?<поиск>
wais://<хост>:<порт>/<база данных>/<wtype>/<wpath>

где <хост> и <порт> соответствуют описанию в разделе 3.1. Если :<port> опущен, по умолчанию используется порт 210. Первая форма обозначает базу данных WAIS, доступную для поиска. Вторая форма обозначает конкретный поиск. <database> — это имя запрашиваемой базы данных WAIS.

Третья форма указывает конкретный документ в базе данных WAIS, который необходимо извлечь. В этой форме <wtype> является обозначением WAIS типа объекта. Многие реализации WAIS требуют, чтобы клиент знал «тип» объекта до извлечения, причем этот тип возвращается вместе с внутренним идентификатором объекта в ответе на поиск. <wtype> включен в URL-адрес, чтобы клиент мог интерпретировать адекватную информацию URL-адреса для фактического извлечения документа.

<wpath> URL-адреса WAIS состоит из идентификатора документа WAIS, закодированного при необходимости с использованием метода, описанного в разделе 2.2. Идентификатор документа WAIS следует рассматривать непрозрачно; он может быть разложен только тем сервером, который его выдал.

3.10 FILES

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

URL-адрес файла имеет вид:

файл://<хост>/<путь>

где <хост> — это полное доменное имя системы, в которой доступен <путь>, а <путь> — это иерархический путь к каталогу в форме <каталог>/<каталог>/…/<имя>.

Например, файл VMS

DISK$USER:[MY.NOTES]NOTE123456.TXT

может стать

<URL: файл://vms.host.edu/disk$user/my/notes/note12345.txt>

В качестве особого случая <host> может быть строкой «localhost» или пустой строкой; это интерпретируется как «машина, с которой интерпретируется URL».

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

3.11 PROSPERO

Схема URL-адресов Prospero используется для обозначения ресурсов, доступ к которым осуществляется через службу каталогов Prospero. Протокол Prospero описан в другом месте [14].

URL-адреса prospero имеют вид:

prospero://<хост>:<порт>/<имя hson>;<поле>=<значение>

где <хост> и <порт> соответствуют описанию в разделе 3.1. Если :<port> опущен, по умолчанию используется порт 1525. Использование имени пользователя или пароля не допускается.

<hsoname> — это имя объекта, зависящее от хоста, в протоколе Prospero, соответствующим образом закодированное. Это имя непрозрачно и интерпретируется сервером Prospero. Точка с запятой «;» зарезервирован и не может отображаться без кавычек в <hsoname>.

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

Обратите внимание, что косая черта «/» может стоять в <hsoname> без кавычек, и приложение может не принимать на себя никакого значения. Хотя косые черты могут указывать на иерархическую структуру на сервере, такая структура не гарантируется. Обратите внимание, что многие <hsoname> начинаются с косой черты, и в этом случае за хостом или портом будет следовать двойная косая черта: косая черта из синтаксиса URL, за которой следует начальная косая черта из <hsoname>. (Например, <URL:prospero://host.dom//pros/name> обозначает <hsoname> из «/pros/name».)

Кроме того, после <hsoname> необязательные поля и значения, связанные со ссылкой Prospero, могут быть указаны как часть URL-адреса. При наличии каждая пара поле/значение отделяется друг от друга и от остальной части URL знаком «;». (точка с запятой). Имя поля и его значение разделяются знаком «=» (знак равенства). Если они присутствуют, эти поля служат для идентификации цели URL-адреса. Например, поле OBJECT-VERSION может быть указано для идентификации конкретной версии объекта.

4. РЕГИСТРАЦИЯ НОВЫХ СХЕМ

Новая схема может быть введена путём определения отображения на соответствующий синтаксис URL с использованием нового префикса. URL-адреса для экспериментальных схем могут использоваться по взаимному согласию сторон. Имена схем, начинающиеся с символов «x-», зарезервированы для экспериментальных целей.

Управление по присвоению номеров в Интернете (IANA) будет вести реестр схем URL. Любая отправка новой схемы URL-адресов должна включать определение алгоритма доступа к ресурсам в рамках этой схемы и синтаксиса для представления такой схемы.

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

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

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

Схема	Описание
afs	Глобальные имена файлов файловой системы Andrew.
mid	Идентификаторы сообщений для электронной почты.
cid	Идентификаторы содержимого для частей тела MIME.
nfs	Имена файлов сетевой файловой системы (NFS).
tn3270	Интерактивные сеансы эмуляции 3270.
mailserver	Доступ к данным, доступным с почтовых серверов.
z39.50	Доступ к службам ANSI Z39.50.

5. BNF для определённых схем URL

Это похожее на BNF описание синтаксиса Унифицированного Указателя Ресурсов с использованием соглашений RFC822, за исключением того, что вертикальная линия «|» используется для обозначения альтернатив, а квадратные скобки «[» и «]» используются вокруг необязательных или повторяющихся элементов. Вкратце, литералы заключаются в кавычки, необязательные элементы заключаются в [квадратные скобки], а элементам может предшествовать <n>* для обозначения n или более повторений следующего элемента; n по умолчанию равен 0.

; Общая форма URL:

genericurl = scheme «:» schemepart

; Здесь определяются конкретные предопределенные схемы; новые схемы могут быть зарегистрированы в IANA

; new schemes follow the general syntax
otherurl = genericurl

; the scheme is in lower case; interpreters should use case-ignore
scheme = 1*[ lowalpha | digit | «+» | «-» | «.» ]

schemepart = *xchar | ip-schemepart

; URL schemeparts for ip based protocols:

ip-schemepart = «//» login [ «/» urlpath ]

; The predefined schemes:

; FTP (see also RFC959)

ftpurl = «ftp://» login [ «/» fpath [ «;type=» ftptype ]]
fpath = fsegment *[ «/» fsegment ]
fsegment = *[ uchar | «?» | «:» | «@» | «&» | «=» ]
ftptype = «A» | «I» | «D» | «a» | «i» | «d»

; FILE

fileurl = «file://» [ host | «localhost» ] «/» fpath

; HTTP

httpurl = «http://» hostport [ «/» hpath [ «?» search ]]
hpath = hsegment *[ «/» hsegment ]
hsegment = *[ uchar | «;» | «:» | «@» | «&» | «=» ]
search = *[ uchar | «;» | «:» | «@» | «&» | «=» ]

; GOPHER (see also RFC1436)

gopherurl = «gopher://» hostport [ / [ gtype [ selector[ «%09» search [ «%09» gopher+_string ] ] ] ] ]
gtype = xchar
selector = *xchar
gopher+_string = *xchar

; MAILTO (see also RFC822)

mailtourl = «mailto:» encoded822addr
encoded822addr = 1*xchar ; further defined in RFC822

; NEWS (see also RFC1036)

newsurl = «news:» grouppart
grouppart = «*» | group | article
group = alpha *[ alpha | digit | «-» | «.» | «+» | «_» ]
article = 1*[ uchar | «;» | «/» | «?» | «:» | «&» | «=» ] «@» host

; NNTP (see also RFC977)

nntpurl = «nntp://» hostport «/» group [ «/» digits ]

; TELNET

telneturl = «telnet://» login [ «/» ]

; WAIS (see also RFC1625)

waisurl = waisdatabase | waisindex | waisdoc
waisdatabase = «wais://» hostport «/» database
waisindex = «wais://» hostport «/» database «?» search
waisdoc = «wais://» hostport «/» database «/» wtype «/» wpath
database = *uchar
wtype = *uchar
wpath = *uchar

; PROSPERO

prosperourl = «prospero://» hostport «/» ppath *[ fieldspec ]
ppath = psegment *[ «/» psegment ]
psegment = *[ uchar | «?» | «:» | «@» | «&» | «=» ]
fieldspec = «;» fieldname «=» fieldvalue
fieldname = *[ uchar | «?» | «:» | «@» | «&» ]
fieldvalue = *[ uchar | «?» | «:» | «@» | «&» ]

; Miscellaneous definitions

lowalpha = «a» | «b» | «c» | «d» | «e» | «f» | «g» | «h» |»i» | «j» | «k» | «l» | «m» | «n» | «o» | «p» |»q» | «r» | «s» | «t» | «u» | «v» | «w» | «x» |»y» | «z»
hialpha = «A» | «B» | «C» | «D» | «E» | «F» | «G» | «H» | «I» |»J» | «K» | «L» | «M» | «N» | «O» | «P» | «Q» | «R» |»S» | «T» | «U» | «V» | «W» | «X» | «Y» | «Z»

alpha = lowalpha | hialpha
digit = «0» | «1» | «2» | «3» | «4» | «5» | «6» | «7» |»8″ | «9»
safe = «$» | «-» | «_» | «.» | «+»
extra = «!» | «*» | «‘» | «(» | «)» | «,»
national = «{» | «}» | «|» | «\» | «^» | «~» | «[» | «]» | «`»
punctuation = «<» | «>» | «#» | «%» | <«>

reserved = «;» | «/» | «?» | «:» | «@» | «&» | «=»
hex = digit | «A» | «B» | «C» | «D» | «E» | «F» | «a» | «b» | «c» | «d» | «e» | «f»
escape = «%» hex hex

6. Вопросы безопасности

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

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

Следует соблюдать осторожность, если URL-адреса содержат встроенные закодированные разделители для данного протокола (например, символы CR и LF для протоколов telnet), чтобы они не были декодированы перед передачей. Это нарушит протокол, но может быть использовано для имитации дополнительной операции или параметра, что опять же приведёт к выполнению неожиданной и возможно вредной удалённой операции.

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

7. Благодарности

Этот документ основан на базовом дизайне WWW (RFC 1630) и активном обсуждении этих вопросов многими людьми в сети. Дискуссию особенно стимулировали статьи Клиффорда Линча, Брюстера Кале [10] и Венгика Йеонга [18]. Были учтены вклады Джона Каррана, Клиффорда Ноймана, Эда Виелметти, а затем рабочей группы IETF URL BOF и URI.

Совсем недавно внимательное прочтение и комментарии Дэна Коннолли, Неда Фрида, Роя Филдинга, Гвидо ван Россума, Майкла Долана, Берта Боса, Джона Кунце, Олле Ярнефорса, Питера Сванберга и многих других помогли уточнить этот RFC.

ПРИЛОЖЕНИЕ: Рекомендации для URL в контексте

URI, включая URL, предназначены для передачи через протоколы, которые обеспечивают контекст для их интерпретации.

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

Кроме того, во многих случаях URL-адреса включаются в тексты других типов; примеры включают электронную почту, новостные сообщения USENET или напечатанные на бумаге. В таких случаях удобно иметь отдельную синтаксическую оболочку, которая ограничивает URL-адрес и отделяет его от остального текста и, в частности, от знаков препинания, которые могут быть ошибочно приняты за часть URL-адреса. Для этого рекомендуется использовать угловые скобки («<» и «>«) вместе с префиксом «URL:» для разграничения границ URL. Эта оболочка не является частью URL-адреса и не должна использоваться в контекстах, в которых уже указаны разделители.

В случае, когда идентификатор фрагмента/якоря связан с URL-адресом (после «#»), идентификатор также будет помещён в скобки.

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

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

Примеры:

Да, Джим, я нашел его по адресу<URL:ftp://info.cern.ch/pub/www/doc;type=d> но вы, вероятно, можете найти его по адресу <URL:ftp://ds.internic.net/rfc>. Обратите внимание на предупреждение в <URL:http://ds.internic.net/instructions/overview.html#WARNING>.

Ссылки

[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti, «The Internet Gopher Protocol (a distributed document search and retrieval protocol)», RFC 1436, University of Minnesota, March 1993.
<URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>

[2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D., Johnson, D., and B. Alberti, «Gopher+: Upward compatible enhancements to the Internet Gopher protocol»,
University of Minnesota, July 1993.
<URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol/Gopher+/Gopher+.txt>

[3] Berners-Lee, T., «Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web», RFC 1630, CERN, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1630.txt>

[4] Berners-Lee, T., «Hypertext Transfer Protocol (HTTP)», CERN, November 1993.
<URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>

[5] Braden, R., Editor, «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, IETF, October 1989.
<URL:ftp://ds.internic.net/rfc/rfc1123.txt>

[6] Crocker, D. «Standard for the Format of ARPA Internet Text Messages», STD 11, RFC 822, UDEL, April 1982.
<URL:ftp://ds.internic.net/rfc/rfc822.txt>

[7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, «WAIS Interface Protocol Prototype Functional Specification», (v1.5), Thinking Machines Corporation, April 1990.
<URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>

[8] Horton, M. and R. Adams, «Standard For Interchange of USENET Messages», RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987.
<URL:ftp://ds.internic.net/rfc/rfc1036.txt>

[9] Huitema, C., «Naming: Strategies and Techniques», Computer Networks and ISDN Systems 23 (1991) 107-110.

[10] Kahle, B., «Document Identifiers, or International Standard Book Numbers for the Electronic Age», 1991.
<URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>

[11] Kantor, B. and P. Lapsley, «Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News», RFC 977, UC San Diego & UC Berkeley, February 1986.
<URL:ftp://ds.internic.net/rfc/rfc977.txt>

[12] Kunze, J., «Functional Requirements for Internet Resource Locators», Work in Progress, December 1994. <URL:ftp://ds.internic.net/internet-drafts
/draft-ietf-uri-irl-fun-req-02.txt>

[13] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
<URL:ftp://ds.internic.net/rfc/rfc1034.txt>

[14] Neuman, B., and S. Augart, «The Prospero Protocol», USC/Information Sciences Institute, June 1993. <URL:ftp://prospero.isi.edu/pub/prospero/doc
/prospero-protocol.PS.Z>

[15] Postel, J. and J. Reynolds, «File Transfer Protocol (FTP)», STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
<URL:ftp://ds.internic.net/rfc/rfc959.txt>

[16] Sollins, K. and L. Masinter, «Functional Requirements for Uniform Resource Names», RFC 1737, MIT/LCS, Xerox Corporation, December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1737.txt>

[17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte, «WAIS over Z39.50-1988», RFC 1625, WAIS, Inc., CNIDR, Thinking Machines Corp., UC Berkeley, FS Consulting, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1625.txt>

[18] Yeong, W. «Towards Networked Information Retrieval», Technical report 91-06-25-01, Performance Systems International, Inc.
<URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.

[19] Yeong, W., «Representing Public Archives in the Directory», Work in Progress, November 1991.

[20] «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4-1986.

Editors’ Addresses

Tim Berners-Lee
World-Wide Web project
CERN,
1211 Geneva 23,
Switzerland

Phone: +41 (22)767 3755
Fax: +41 (22)767 7155
EMail: timbl@info.cern.ch

Larry Masinter
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94034

Phone: (415) 812-4365
Fax: (415) 812-4333
EMail: masinter@parc.xerox.com

Mark McCahill
Computer and Information Services,
University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455

Phone: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu