lwp::protocol::ldap(3) [osx man page]
LWP::Protocol::ldap(3) User Contributed Perl Documentation LWP::Protocol::ldap(3) NAME
LWP::Protocol::ldap - Provide LDAP support for LWP::UserAgent SYNOPSIS
use LWP::UserAgent; $ua = LWP::UserAgent->new(); $res = $ua->get('ldap://ldap.example.com/' . 'o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)', Accept => 'text/json'): DESCRIPTION
The LWP::Protocol::ldap module provides support for using ldap schemed URLs following RFC 4516 with LWP. This module is a plug-in to the LWP protocol handling, so you don't use it directly. In addition to being used with LDAP URIs, LWP::Protocol::ldap also acts as the base class for its sibling modules LWP::Protocol::ldaps and LWP::Protocol::ldapi. Features HTTP methods supported LWP::Protocol::ldap implements the HTTP GET and HEAD methods. They are mapped to the LDAP search operation, Response format Depending on the HTTP Accept header provided by the user agent, LWP::Protocol::ldap can answer the requests in one of the following formats: DSML When the HTTP Accept header contains the "text/dsml" MIME type, the response is sent as DSMLv1. JSON When the HTTP Accept header contains the "text/json" MIME type, the response is sent as JSON. For this to work the JSON Perl module needs to be installed. LDIF When the HTTP Accept header contains the "text/ldif" MIME type, the response is sent in LDIFv1 format. HTML In case no HTTP Accept header has been sent or none of the above MIME types can be detected, and the x-format extension has not been provided either, the response is sent using HTML markup in a 2-column table format (roughly modeled on LDIF). As an alternative to sending an HTTP Accept header, LWP::Protocol::ldap also accepts the "x-format" extension Example: ldap://ldap.example.com/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)?x-format=dsml TLS support For ldap and ldapi URIs, the module implements the "x-tls" extension that switches the LDAP connection to TLS using a call of the start_tls method. Example: ldap://ldap.example.com/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)?x-tls=1 Note: In the above example, ideally giving "x-tls" should be sufficient, but unfortunately the parser in URI::ldap has a little flaw. Authorization Usually the connection is done anonymously, but if the HTTP Authorization header is provided with credentials for HTTP Basic authorization, the credentials given in that header will be used to do a simple bind to the LDAP server. SEE ALSO
LWP::Protocol::ldaps, LWP::Protocol::ldapi COPYRIGHT
Copyright (c) 1998-2004 Graham Barr, 2012 Peter Marschall. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.16.2 2012-09-20 LWP::Protocol::ldap(3)
Check Out this Related Man Page
LWP(3pm) User Contributed Perl Documentation LWP(3pm) NAME
Coro::LWP - make LWP non-blocking - as much as possible SYNOPSIS
use Coro::LWP; # afterwards LWP should not block ALTERNATIVES
Over the years, a number of less-invasive alternatives have popped up, which you might find more acceptable than this rather invasive and fragile module. All of them only support HTTP (and sometimes HTTPS). AnyEvent::HTTP Works fine without Coro. Requires using a very different API than LWP. Probably the best choice iff you can do with a completely different event-based API. LWP::Protocol::AnyEvent::http Makes LWP use AnyEvent::HTTP. Does not make LWP event-based, but allows Coro threads to schedule unimpeded through its AnyEvent integration. Let's you use the LWP API normally. LWP::Protocol::Coro::http Basically the same as above, distinction unclear. :) AnyEvent::HTTP::LWP::UserAgent A different user agent implementation, not completely transparent to users, requires Coro. DESCRIPTION
This module is an AnyEvent user, you need to make sure that you use and run a supported event loop. This module tries to make LWP non-blocking with respect to other coroutines as much as possible, and with whatever means it takes. LWP really tries very hard to be blocking (and relies on a lot of undocumented functionality in IO::Socket), so this module had to be very invasive and must be loaded very early to take the proper effect. Note that the module AnyEvent::HTTP might offer an alternative to the full LWP that is designed to be non-blocking. Here is what it currently does (future versions of LWP might require different tricks): It loads Coro::Select, overwriting the perl "select" builtin globally. This is necessary because LWP calls select quite often for timeouts and who-knows-what. Impact: everybody else uses this (slower) version of select, too. It should be quite compatible to perls builtin select, though. It overwrites Socket::inet_aton with Coro::Util::inet_aton. This is necessary because LWP might (and does) try to resolve hostnames this way. Impact: some code might not expect coroutine semantics, for example, when you fork you might prefer the blocking variant because other coroutines shouldn't actually run. It replaces the base class of Net::HTTP, Net::FTP, Net::NNTP. This is necessary because LWP does not always use select to see whether a filehandle can be read/written without blocking, so the base class "IO::Socket::INET" needs to be replaced by "Coro::Socket". Impact: Coro::Socket is not at all compatible to IO::Socket::INET. While it duplicates some undocumented functionality required by LWP, it does not have all the methods of IO::Socket::INET and might act quite differently in practise. Also, protocols other than the above mentioned will still block, at least some of the time. All this likely makes other libraries than just LWP not block, but thats just a side effect you cannot rely on. Increases parallelism is not supported by all libraries, some might cache data globally. AUTHOR
Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/ perl v5.14.2 2012-04-13 LWP(3pm)