globus_gass_transfer_referral(3) [debian man page]

Referrals(3)						       globus gass transfer						      Referrals(3)

NAME

       Referrals -

   Functions
       globus_size_t globus_gass_transfer_referral_get_count (globus_gass_transfer_referral_t *referral)
       char * globus_gass_transfer_referral_get_url (globus_gass_transfer_referral_t *referral, globus_size_t index)
       int globus_gass_transfer_referral_destroy (globus_gass_transfer_referral_t *referral)

Detailed Description
       The GASS Transfer API supports referring URL requests to alternate URLs via referrals.

       Referrals are essentially pointers to another URL or URLs which contain the same file as the original location which a client has requested
       of a server. Referrals may span multiple protocol schemes, though not all protocols may be able to generate referrals. For example, an HTTP
       server may refer a client to another HTTP server, an HTTPS server.

       Upon receiving a referred response from a server, a client should query the request handle to determine from where the file can be
       retrieved.

Function Documentation
   globus_size_t globus_gass_transfer_referral_get_count (globus_gass_transfer_referral_t *referral)
       Get the number of URLs in this referral. This function examines the referral to determine if the number of URLs which are contained in it.
       Each of these URLs should either point to another referral, or to a URL containing the equivalent file as the original URL request which
       caused this referral.

       Parameters:
	   referral The referral structure to query.

       Returns:
	   This function returns the number of URL entries in the referral, or 0, if there are none.

   char* globus_gass_transfer_referral_get_url (globus_gass_transfer_referral_t *referral, globus_size_tindex)
       Get a URL string from a referral. This function examines the referral to retrieve a URL string from it. A valid referal will contain one or
       more strings. They are indexed from 0 to the value returned by globus_gass_transfer_referral_get_count() - 1.

       The string returned by this function must not be freed by the caller. It will remain valid until the referral structure is destroyed.

       Parameters:
	   referral The referral structure to query.
	   index The URL to extract from the referral.

       Returns:
	   This function returns a string pointer containing the URL, or NULL if the index or referral were invalid.

   int globus_gass_transfer_referral_destroy (globus_gass_transfer_referral_t *referral)
       Free all memory used by a referral. This function frees all memory used by this referral. After calling this function, the strings returned
       by calling globus_gass_transfer_referral_get_url() must not be accessed. Any further attempts to extract informatoin from this referral
       will fail.

       Parameters:
	   referral The referral to destroy.

       Return values:
	   GLOBUS_SUCCESS The referral was successfully destroyed.
	   GLOBUS_GASS_TRANSFER_ERROR_NULL_POINTER The referral parameter was GLOBUS_NULL. It could not be destroyed.

Author
       Generated automatically by Doxygen for globus gass transfer from the source code.

Version 7.2							  Mon Apr 30 2012						      Referrals(3)

SLAPO-CHAIN(5)							File Formats Manual						    SLAPO-CHAIN(5)

NAME

       slapo-chain - chain overlay to slapd

SYNOPSIS

       /etc/ldap/slapd.conf

DESCRIPTION

       The  chain  overlay  to	slapd(8)  allows  automatic referral chasing.  Any time a referral is returned (except for bind operations), it is
       chased by using an instance of the ldap backend.  If operations are performed with an identity (i.e. after a bind), that  identity  can	be
       asserted  while	chasing  the  referrals  by means of the identity assertion feature of back-ldap (see slapd-ldap(5) for details), which is
       essentially based on the proxied authorization control [RFC 4370].  Referral chasing can be controlled by the client by issuing the  chain-
       ing control (see draft-sermersheim-ldap-chaining for details.)

       The  config directives that are specific to the chain overlay are prefixed by chain-, to avoid potential conflicts with directives specific
       to the underlying database or to other stacked overlays.

       There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be  implic-
       itly  instantiated  by  the  overlay  may  assume  a  special  meaning  when  used in conjunction with this overlay.  They are described in
       slapd-ldap(5), and they also need to be prefixed by chain-.

       Note: this overlay is built into the ldap backend; it is not a separate module.

       overlay chain
	      This directive adds the chain overlay to the current backend.  The chain overlay may be used with any  backend,  but  it	is  mainly
	      intended	for  use  with	local  storage	backends  that may return referrals.  It is useless in conjunction with the slapd-ldap and
	      slapd-meta backends because they already exploit the libldap specific referral chase feature.  [Note: this may change in the future,
	      as the ldap(5) and meta(5) backends might no longer chase referrals on their own.]

       chain-cache-uri {FALSE|true}
	      This  directive  instructs  the  chain  overlay  to cache connections to URIs parsed out of referrals that are not predefined, to be
	      reused for later chaining.  These URIs inherit the properties configured for the underlying slapd-ldap(5) before any  occurrence	of
	      the chain-uri directive; basically, they are chained anonymously.

       chain-chaining [resolve=<r>] [continuation=<c>] [critical]
	      This directive enables the chaining control (see draft-sermersheim-ldap-chaining for details) with the desired resolve and continua-
	      tion behaviors and criticality.  The resolve parameter refers to the behavior while discovering a resource,  namely  when  accessing
	      the  object  indicated  by  the request DN; the continuation parameter refers to the behavior while handling intermediate responses,
	      which is mostly significant for the search operation, but may affect extended operations that return  intermediate  responses.   The
	      values  r  and  c  can  be  any of chainingPreferred, chainingRequired, referralsPreferred, referralsRequired.  If the critical flag
	      affects the control criticality if provided.  [This control is experimental and its support may change in the future.]

       chain-max-depth <n>
	      In case a referral is returned during referral chasing, further chasing occurs at most <n> levels deep.  Set to 1 (the  default)	to
	      disable further referral chasing.

       chain-return-error {FALSE|true}
	      In  case	referral  chasing  fails, the real error is returned instead of the original referral.	In case multiple referral URIs are
	      present, only the first error is returned.  This behavior may not be always appropriate nor desirable, since  failures  in  referral
	      chasing might be better resolved by the client (e.g. when caused by distributed authentication issues).

       chain-uri <ldapuri>
	      This  directive  instantiates  a	new  underlying  ldap database and instructs it about which URI to contact to chase referrals.	As
	      opposed to what stated in slapd-ldap(5), only one URI can appear after this directive; all subsequent slapd-ldap(5) directives  pre-
	      fixed by chain- refer to this specific instance of a remote server.

       Directives for configuring the underlying ldap database may also be required, as shown in this example:

	      overlay		      chain
	      chain-rebind-as-user    FALSE

	      chain-uri 	      "ldap://ldap1.example.com"
	      chain-rebind-as-user    TRUE
	      chain-idassert-bind     bindmethod="simple"
				      binddn="cn=Auth,dc=example,dc=com"
				      credentials="secret"
				      mode="self"

	      chain-uri 	      "ldap://ldap2.example.com"
	      chain-idassert-bind     bindmethod="simple"
				      binddn="cn=Auth,dc=example,dc=com"
				      credentials="secret"
				      mode="none"

       Any valid directives for the ldap database may be used; see slapd-ldap(5) for details.  Multiple occurrences of the chain-uri directive may
       appear, to define multiple "trusted" URIs where operations with identity assertion are chained.	All URIs not listed in	the  configuration
       are chained anonymously.  All slapd-ldap(5) directives appearing before the first occurrence of chain-uri are inherited by all URIs, unless
       specifically overridden inside each URI configuration.

FILES

       /etc/ldap/slapd.conf
	      default slapd configuration file

SEE ALSO

       slapd.conf(5), slapd-config(5), slapd-ldap(5), slapd(8).

AUTHOR

       Originally implemented by Howard Chu; extended by Pierangelo Masarati.

OpenLDAP							    2012/04/23							    SLAPO-CHAIN(5)