![]() ![]() ![]() ![]() |
Contents |
A referral is a way of redirecting a client's request to another server. A referral contains the names and locations of other objects. It is sent by the server to indicate that the information the client has requested could be found at other location (or locations), possibly at another server or several servers.This lesson shows you how to handle referrals using the JNDI. It starts off with an overview of referrals and a description of the mechanisms available in the JNDI for handling referrals. It then describes how to ignore them, and how to handle them automatically and manually. Finally, it shows you how to create a referral entry and to update an existing referral entry.
Comparison with Alias
In many ways, a referral is a generalization of an alias, which is discussed in the Miscellaneouslesson. An alias contains the distinguished name of another object, while a referral contains one or more URLs of objects. The URLs are usually LDAP URLs, but are not restricted to being so. The LDAP URL contains the host/port of the server and the distinguished name of an object. The host/port information in the URL can point to a directory server different from the one that returned the referrral object.
While an alias is dereferenced and processed by the server, referrals are returned to the client, which is responsible for processing them.
Uses
Like aliases, referrals are useful for allowing an object to be identified by different names. Referrals can be used, for example, to accommodate the namespace changes and mergers that are inevitable as organizations evolve. In addition, referrals allow directory administrators to set up "search paths" for collecting results from multiple servers. Referrals can also be used for deploying cache or read-only server replicas that return referrals for all update requests. Read-only replicas are among the many different load balancing strategies that can be implemented using referrals.
Version 2 Versus Version 3
In the LDAP v2, referrals are supported in a limited way. An LDAP v2 server can be configured with a "default" referral, such that if the information requested at the server does not exist, the server returns a "partial result" error response containing the referral URL. When the client receives a "partial result" error, it checks whether the referral URL is present and uses it instead of interpreting the response as a "partial result" error. The client uses the referral URL by contacting the server named in it to continue the requested operation.The LDAP v3 explicitly supports referrals and allows servers to return the referrals directly to the client. The server can return to the client a "referral" error response for any request that requires a response. This error response contains one or more URLs that are to be used to continue the operation. All the URLs in the response are equivalent, in that using any one of them should yield the correct result. The client should select one of these URLs to continue the operation.
In addition, during an LDAP "search" operation, a server can return a number of continuation references, which are of the same data type as a referral. The client is required to follow all continuation references. Like a referral, each continuation reference itself may contain a number of URLs assumed to be equivalent, and the client should use one of those URLs. Unless a distinction is required, this lesson uses the term "referral" to mean the referral that is returned in either an error response or a continuation reference.
![]() ![]() ![]() ![]() |
Contents |