#47610 Perl NET::LDAP fails to get paged results(Cookies)
Closed: wontfix None Opened 10 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1034481

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:

When using "Single paged results"  ( RFC 2696 ) when running search queries on
Redhat Directory Server 9 using the perl module NET::LDAP  (this is the
standard code from CPAN for "Single paging", nothing special.)

what happens is that after a first page the program stops, this means that the
cookie is not received from the LDAP server the problem is in line:

$cookie    = $resp->cookie or last;

the loop is exited because the cookie is not received and this the following
pages are not displayed and the paging does not work.

Version-Release number of selected component: 389-ds-base-1.2.11.15-30.el6_5

How reproducible: Always

Steps to Reproduce:
1. Use the (attached) perl program to get entries from Directory Server


Actual results: The program unable to find the cookie, so it stops processing
after receiving the first entry.


Expected results: The program get the cookie and uses the same to get next
entry.


Additional info:

Per customer, The program works on Oracle Unified Directory and OpenDJ, I did
test the script using openldap and it works fine with OpenLDAP server.

The only thing I noticed is, openldap returns 'searchResEntry' and
'searchResDone' in different packets, 389-ds includes both in the same packet.

RHDS is sending back valid values. You can run the script like this:

my $ldap = Net::LDAP->new($LdapServer, debug => 8) or die "##ERROR## connecting to LDAP server $LdapServer .\n";

You will see output like this:

Net::LDAP=HASH(0x15dcf30) received:
0000 50: SEQUENCE {
0002 1: INTEGER = 2
0005 7: [APPLICATION 5] {
0007 1: ENUM = 0
000A 0: STRING = ''
000C 0: STRING = ''
000E : }
000E 36: [CONTEXT 0] {
0010 34: SEQUENCE {
0012 22: STRING = '1.2.840.113556.1.4.319'
002A 8: STRING
002C : 30 06 02 01 09 04 01 30 0......0
0034 : }
0034 : }
0034 : }

The paged result response value contains the size and the cookie (starting at 002C):

30 - start sequence
06 - 6 bytes follow
02 - integer tag (size tag)
01 - length of integer (size length)
09 - value of integer (this is the $resp size)
04 - octet string tag (cookie tag)
01 - string length (cookie length)
30 - string value (cookie value - e.g. the string "0")

The problem is this line:
$cookie = $resp->cookie or last;

Note that in perl, the string "0" is automatically converted to a decimal 0 for the boolean test using the "or". Thus, the test fails because 0 is also the perl value for FALSE.

Looking at the RFC http://tools.ietf.org/html/rfc2696
3. Client-Server Interaction
The cookie (from the server) MUST be set to an
empty value if there are no more entries to return (i.e., the page of
search results returned was the last), or, if there are more entries
to return, to an octet string of the server's choosing,used to resume
the search.

Note that the result sent by the server for the cookie value is "0", which is NOT an empty value. The better test in perl would be something like this:

$cookie = $resp->cookie;
if (defined($cookie) && length($cookie)) {
print "DDB debug0.4 \n";
print "DDB debug0.5 $cookie \n";
} else {
last;
}

# Set cookie in paged control
$page->cookie($cookie);

I'm closing this issue as NOTABUG.

Metadata Update from @rmeggins:
- Issue set to the milestone: N/A

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/947

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata