An LDAP URL Format
obsoleted by
- rfc-2255 — The LDAP URL Format
Extracted elements (15)
Omitting the `<hostport>` component from an LDAP URL is intentionally supported so that URLs referencing X.500 namespace entries can be resolved by any available X.500-capable LDAP server, enabling location-independent references to directory entries.
The `<scope>` and `<filter>` components are made optional with well-defined defaults (`base` scope and `(objectClass=*)` filter) to allow concise LDAP URLs that reference a single known entry without requiring explicit search parameters.
The URL format is designed to be general enough to handle both LDAP servers acting as X.500 front-ends and stand-alone LDAP servers not backed by X.500, anticipating future deployment scenarios beyond the then-current X.500 front-end use case.
If an entry resides in the X.500 namespace, it should be reachable from any LDAP server providing front-end access to X.500. If the `<hostport>` part of the URL is missing, the URL can be resolved by contacting any X.500-back-ended LDAP server.
If `<filter>` is omitted from the LDAP URL, a filter of `(objectClass=*)` is assumed, which matches all object classes and effectively retrieves any entry in scope.
If `<scope>` is omitted from the LDAP URL, a scope of `"base"` (base object search) is assumed by the client resolving the URL.
If the `<attributes>` part of the URL is omitted, all attributes of the matching entry or entries should be returned by the LDAP server.
The default port for LDAP connections resolved from an LDAP URL is TCP port 389, used when no explicit `<portnumber>` is included in the `<hostport>` component.
URL-illegal characters in the `<dn>` and `<filter>` components (e.g., spaces) MUST be escaped using the % method described in RFC 1738 to produce a valid LDAP URL.
The `<attributes>` component specifies which attributes should be returned from matched entries. It is either NULL or a comma-separated list of `<attributetype>` names as defined in RFC 1777. If omitted, all attributes are returned.
The `<dn>` component of the LDAP URL is an LDAP Distinguished Name using the string format defined in RFC 1485 (later RFC 1779), with URL-illegal characters percent-encoded using the method described in RFC 1738.
The `<filter>` component is an LDAP search filter string as defined in RFC 1558 (LDAP search filter syntax), with URL-illegal characters percent-encoded. If omitted, a filter of `(objectClass=*)` is assumed.
The `<scope>` component specifies the LDAP search scope: `"base"` for a base object search, `"one"` for a one-level search, or `"sub"` for a subtree search. If omitted, `"base"` is assumed.
The LDAP URL format provides no mechanism to specify credentials for resolving the URL; therefore, such requests are expected to be unauthenticated. The security implications of resolving an LDAP URL are the same as those of resolving any LDAP query, as described in RFC 1777.
An LDAP URL is defined by the grammar: `ldap://[<hostport>]/<dn>[?<attributes>[?<scope>?<filter>]]`. The `<hostport>` is `<hostname>[:<portnumber>]`, defaulting to TCP port 389. All URL-illegal characters (e.g., spaces) must be percent-encoded per RFC 1738.