[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
This is a multi-part message in MIME format.
------_=_NextPart_001_01C7DFD5.8B035F66
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
=20
thanks for your replies. Anyway i did not opened this message to discuss
who implented RFC 2696 correctly and who not. The point is something
else:
=20
1) I tried to share my experience (and solution) with other LDAP
application programmers, since i am pretty sure there are/will be more
clients running into this issue (e.g. ldp.exe from Windows support tools
seems to have the same problem when enabling 1.2.840.113556.1.4.319 /
pages search type again slapd).
2) Try to point out how it can easily happen to write a client working
with Active Directory but not with slapd and suggested an easy but
perhaps not 100% RFC 2696 compliant slapd change.
=20
Perhaps i should explain 2) a little bit more from my application
develeopers point of view. Here is my rough application history:
=20
a) In ~1999 we started building a LDAP V3 client for SAP that had to
work on a very wide variety of OS platforms and as much as possible LDAP
V3 compliant directories.
b) It was first shipped in 2000/2001 and customers were happy.
c) Data volume at customer side increazed and it stopped working for
Active Directory customers.
d) We learned about size limits, page size and the fact you simply have
to use 1.2.840.113556.1.4.319 to get more than 1000 entries from Active
Directroy. We implemented it and everybody was happy again. Implenting
ldap_create_page_control for all OS platforms was not that trivial at
that time.
e) In ~2004 the first customer liked to use slapd. We noticed some minor
issues (e.g. setting V3 protocol version explicitly) fixed it and once
more everybody was happy.
f) Yesterday a slapd 2.3.35 slapd customer reported a problem similar to
e) ("Protocol Error"). So we analyzed it and fixed it again by reducing
default page size to 2**31-1.
=20
Here is why i believe others might run into the same issue. If you need
to create a ldap client dealing with big search results for various LDAP
directories you had to use 1.2.840.113556.1.4.319 even if you are only
interested in collecting the entire result otherwise you would fail with
Active Directory. You look at the ldap_create_page_control API spec
(developers oftern use API specs and not protocol RFCs) and notice page
size to be an usinged integer. Since you are not really interested in
pages you specify the largest possible value 2**32-1. This way you end
up with client working with Active Directory, all directories not
supporting 1.2.840.113556.1.4.319 but not with slapd supporting
1.2.840.113556.1.4.319.
=20
I am not interested in discussing who is right and who is wrong, i am
just interested in making as much as possible working together in the
real world with as little as possible customer pain. Therefore i am
almost 100% sure Active Directory will not break existing clients by
using signed instead of unsigned integer page size just to be more RFC
2696 compliant.On the other hand slapd has a chance to detect negavtive
page sizes and assume some reasonable page size in that situation
instead of "Protocol Error" without breaking any existing client. For my
customers it will not make much difference since the patch will be
rolled out soon, but perhaps others can benefit.
=20
Best regards
Randolf
=20
=20
------_=_NextPart_001_01C7DFD5.8B035F66
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.3790.2920" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>thanks =
for your=20
replies. Anyway i did not opened this message to discuss who implented =
RFC 2696=20
correctly and who not. The point is something=20
else:</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>1) I =
tried to share=20
my experience (and solution) with other LDAP application programmers, =
since i am=20
pretty sure there are/will be more clients running into this issue (e.g. =
ldp.exe=20
from Windows support tools seems to have the same problem when enabling=20
1.2.840.113556.1.4.319 / pages search type again =
slapd).</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>2) Try =
to point out=20
how it can easily happen to write a client working with Active Directory =
but not=20
with slapd and suggested an easy but perhaps not 100% RFC 2696 compliant =
slapd=20
change.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial =
size=3D2>Perhaps i should=20
explain 2) a little bit more from my application develeopers point of =
view. Here=20
is my rough application history:</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>a) In =
~1999 we=20
started building a LDAP V3 client for SAP that had to work on a very =
wide=20
variety of OS platforms and as much as possible LDAP V3 compliant=20
directories.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>b) It =
was first=20
shipped in 2000/2001 and customers were happy.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>c) =
Data volume at=20
customer side increazed and it stopped working for Active Directory=20
customers.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>d) We =
learned about=20
size limits, page size and the fact you simply have to use=20
1.2.840.113556.1.4.319 to get more than 1000 entries from Active=20
Directroy. We implemented it and everybody was happy again. Implenting=20
ldap_create_page_control for all OS platforms was not that trivial at =
that=20
time.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>e) In =
~2004 the=20
first customer liked to use slapd. We noticed some minor issues (e.g. =
setting V3=20
protocol version explicitly) fixed it and once more everybody was=20
happy.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>f) =
Yesterday a slapd=20
2.3.35 slapd customer reported a problem similar to e) ("Protocol =
Error"). So we=20
analyzed it and fixed it again by reducing default page size to=20
2**31-1.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>Here =
is why i=20
believe others might run into the same issue. If y</FONT></SPAN><SPAN=20
class=3D021122006-16082007><FONT face=3DArial size=3D2>ou need to create =
a ldap client=20
dealing with big search results for various LDAP directories you had to =
use=20
1.2.840.113556.1.4.319 even if you are only interested in collecting the =
entire=20
result otherwise you would fail with Active Directory. You look at the=20
ldap_create_page_control API spec (developers oftern use API specs and =
not=20
protocol RFCs) and notice page size to be an usinged integer. Since you =
are not=20
really interested in pages you specify the largest possible value =
2**32-1.=20
This way you end up with client working with Active Directory, all=20
directories not supporting 1.2.840.113556.1.4.319 but not with =
slapd=20
supporting 1.2.840.113556.1.4.319.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>I am =
not interested=20
in discussing who is right and who is wrong, i am just interested in =
making as=20
much as possible working together in the real world with as little as =
possible=20
customer pain. Therefore i am almost 100% sure Active Directory will not =
break=20
existing clients by using signed instead of unsigned integer page size =
just to=20
be more RFC 2696 compliant.On the other hand slapd has a chance to =
detect=20
negavtive page sizes and assume some reasonable page size in that =
situation=20
instead of "Protocol Error" without breaking any existing client. For my =
customers it will not make much difference since the patch will be =
rolled=20
out soon, but perhaps others can benefit.</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial size=3D2>Best=20
regards</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial =
size=3D2> =20
Randolf</FONT></SPAN></DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D021122006-16082007><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV></BODY></HTML>
------_=_NextPart_001_01C7DFD5.8B035F66--