Кратко

  • RFC 1959 объединил в переносимом URL местоположение сервера LDAP, distinguished name, возвращаемые атрибуты, область поиска и фильтр; пропуски включали заданные по умолчанию параметры.
  • Хост можно было не указывать, а поля для учётных данных не существовало. Одна строка могла выполняться при разных серверах, соединениях и правилах доступа.
  • URL фиксировал намерение выполнить поиск, но не доказывал фактическое исполнение, полноту ответа или полномочие на дальнейшее действие.

Запрос получил переносимую оболочку

LDAP создавался как облегчённый доступ к каталогу X.500. RFC 1959 стремился дать интернет-клиентам прямой путь к протоколу и одновременно допускал самостоятельные серверы LDAP. Новшеством был не новый источник истины, а компактная оболочка существующей операции.

Порядок компонентов был фиксирован: ldap://, необязательные хост и порт, затем косая черта с distinguished name, после неё атрибуты, область и фильтр, разделённые вопросительными знаками. Хост указывал сервер; имя — базу поиска; атрибуты — желаемые поля; область — базовый объект, один уровень или поддерево; фильтр — подходящие записи.

У фильтра уже была собственная история: RFC 1558 описывал текстовую грамматику исполняемого предиката LDAP. RFC 1959 определял конверт, перевозивший этот предикат вместе с другими параметрами. Фильтр не выбирал сервер и не выдавал права; URL не отменял внутреннюю грамматику фильтра.

Пустые позиции запускали значения по умолчанию

При отсутствии порта использовался TCP 389. Без списка атрибутов запрашивались все атрибуты. Без области выбирался base. Без фильтра применялся (objectClass=*). Эти правила достраивали вопрос клиента, а не описывали состояние каталога.

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

В примере поиска по поддереву University of Michigan два вопросительных знака шли подряд: пустое поле атрибутов сохраняло позиции sub и фильтра. Поэтому аудиту нужен не только написанный текст, но и список параметров, появившихся из-за пропусков.

Distinguished name и фильтр сохраняли свои синтаксисы, а неподходящие для URL символы кодировались по RFC 1738. Проверенная errata 528 исправляет ссылку на синтаксис DN с RFC 1485 на RFC 1779. Процентное кодирование обеспечивало перенос, но не делало имя каноническим, фильтр безопасным или утверждение истинным.

Пропущенный хост оставлял выбор вне строки

Форма ldap:/// не называла сервер. Для записи в пространстве X.500 RFC 1959 разрешал обратиться к любому серверу LDAP с доступом к X.500. Ссылка меньше зависела от одной машины, но не сообщала алгоритм выбора, реплику, представление данных или время ответа. «Любой» не означало «все» и не было печатью глобального авторитета.

RFC 2255 позже сделал границу явнее. Без хоста клиенту требовалось заранее знать подходящий сервер. Он мог создать или повторно использовать соединение, выбрать безопасность и аутентификацию, а также задать не выраженные в URL поля SearchRequest: пределы размера и времени, обработку псевдонимов и другие параметры.

Нельзя задним числом считать эти пояснения содержимым RFC 1959. Формат 1996 года не включал алгоритм выбора сервера, историю соединения, лимиты исполнения или политику псевдонимов.

URL не содержал удостоверения личности

RFC 1959 не предусматривал учётных данных и ожидал неаутентифицированное разрешение URL. Анонимный поиск может быть намеренно разрешён для открытых данных. Однако он не создаёт права получить всё запрошенное.

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

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

Результат начинался после вопроса

RFC 4511 описывает ноль или больше записей и ссылок, затем SearchResultDone с успехом или ошибкой. RFC 1959 не помещал эту последовательность в URL и не замораживал снимок каталога.

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

RFC 4516, действующий стандарт URL LDAPv3, отмечает, что формат выражает не все параметры SearchRequest. URL меньше операции, а операция меньше решения потребляющей системы.

Через принцип Minimum Initial Specification Хэн Лу эта ограниченность выглядит достоинством: малая общая поверхность облегчает координацию, не присваивая постоянную власть. Running-Code Primacy требует отдельных свидетельств для строки, интерпретации, соединения, сообщений и действия. RFC 1959 позволил вопросу путешествовать, но не сделал его суверенным.

Источники и пределы

Статус документа указан в IETF Datatracker и на странице RFC Editor. Исходный текст доступен в HTML и текстовом формате; errata 528 исправляет ссылку на DN. Контекст дают RFC 1777, RFC 1558 и RFC 1738, дальнейшие границы — RFC 2255, RFC 4511 и RFC 4516.

Редакционная рамка использует тексты Хэн Лу Running-Code Primacy, Minimum Initial Specification и Reality Layers. Они не являются доказательством внедрения LDAP. Источники подтверждают спецификации и заявленные границы, но не современное применение, соответствие продуктов, реальные данные, инциденты, ACL или решения приложений.