From users-return-789-apmail-directory-users-archive=directory.apache.org@directory.apache.org Tue Aug 28 17:21:00 2007 Return-Path: Delivered-To: apmail-directory-users-archive@www.apache.org Received: (qmail 82384 invoked from network); 28 Aug 2007 17:20:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Aug 2007 17:20:58 -0000 Received: (qmail 44229 invoked by uid 500); 28 Aug 2007 17:20:46 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 44206 invoked by uid 500); 28 Aug 2007 17:20:46 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 44168 invoked by uid 99); 28 Aug 2007 17:20:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 10:20:46 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [81.169.146.161] (HELO mo-p00-ob.rzone.de) (81.169.146.161) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 17:21:36 +0000 Received: from [127.0.0.1] (p548FD1E3.dip.t-dialin.net [84.143.209.227]) by post.webmailer.de (mrclete mo45) (RZmta 12.1) with ESMTP id 606648j7SGnsCn for ; Tue, 28 Aug 2007 19:20:20 +0200 (MEST) Message-ID: <46D459A3.80707@labeo.de> Date: Tue, 28 Aug 2007 19:21:39 +0200 From: Stefan Zoerner User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: users@directory.apache.org Subject: Re: Unrequested attributes returned on ldap search References: <46D435E6.1080108@labeo.de> <46D43683.3050007@labeo.de> <46D44653.60906@labeo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: kR2YrGeU3i5GJZNxbYfAbITnBeX/YWiFZ/RSZNN7D9RkvGeI3+0E6FAJhQ== X-RZG-CLASS-ID: mo00 X-Virus-Checked: Checked by ClamAV on apache.org Emmanuel Lecharny wrote: > This is a clear client bug. The client just add an empty attribute at > the end of the attributes list : > ... > 30 06 // Attributes list > 04 02 // 2 chars length attribute > sn // sn is requested > 04 00 // 0 length attribute. > > In this very case, we are 'interpreting the spec by considering that > asking for an empty attribute means we want all the attributes ("*") > (nothing in the RFC states that if we have an empty attribute we > should discard it, but if the list is itself empty, then it should be > considered as '*'. I added a special case : if one attribute is empty, > then it is considered as if the user injected a '*'). You definitely breathe the byte streams ;-) Nevertheless I would recommend to raise a JIRA, I'll assign it to me. Later on I'll check all relevant LDAP servers, and see how they interpret this. And I will check whether this is a general Java SDK problem. If so, it is relevant. I don't think that migrating to a newer version of the SDK would help our users. If this is a problem related to the SDK (and not the LDAPSearch client of the SDK) we should consider to change the behavior, at least if all other servers behave differently. We can still mark it as "invalid", but we have documented our decision and the behavior in case others face the same problem. What do you think?