Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 51938 invoked from network); 23 Sep 2005 02:56:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Sep 2005 02:56:25 -0000 Received: (qmail 17574 invoked by uid 500); 23 Sep 2005 02:56:24 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 17524 invoked by uid 500); 23 Sep 2005 02:56:24 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 17511 invoked by uid 99); 23 Sep 2005 02:56:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2005 19:56:24 -0700 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=HTML_30_40,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.162.196 as permitted sender) Received: from [64.233.162.196] (HELO zproxy.gmail.com) (64.233.162.196) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2005 19:56:31 -0700 Received: by zproxy.gmail.com with SMTP id q3so467588nzb for ; Thu, 22 Sep 2005 19:56:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=PRjvpA0MAQaZnBmwvw010YLuaKfHB7kaUSJsHpWype8eh9oAso/LZuaDMhgZmDzl7auBxWRoVMVM7bnIv/Gh1wOOob0P6ltLJb96eGLgBMpUg4uD6/A0brGLHeeFbLChzGipt/RUUyjtnFbGAh3ckN/UNyFgTd9GR9pbeuiOolc= Received: by 10.54.41.8 with SMTP id o8mr113065wro; Thu, 22 Sep 2005 19:56:01 -0700 (PDT) Received: by 10.54.71.11 with HTTP; Thu, 22 Sep 2005 19:56:01 -0700 (PDT) Message-ID: <768dcb2e05092219565a116bfd@mail.gmail.com> Date: Fri, 23 Sep 2005 11:56:01 +0900 From: Trustin Lee Reply-To: Trustin Lee To: Norbet Reilly , Apache Directory Developers List Subject: Re: DIREVE-253 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7893_1856739.1127444161286" References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_7893_1856739.1127444161286 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Norbert, 2005/9/23, Norbet Reilly : > > Hi Trustin, > Just thought I might mention this issue to you as well, as I gather from > your postings that you are the MINA guru, and my limitted understanding o= f > the root cause under this issue leads me to suspect that the MINA level m= ay > be involved in some way. > MINA is just a network application framework. It doesn't have relationship with escaping IMHO. You'd better to look at the LDAP protocol handler and LDAP codec. You can locate them at: * protocol-providers\ldap\trunk * shared\ldap\trunk I know you guys are really busy, but if you get a second to scan the issue > (and reassign the component if reqd) that would be great. I'm happy to > investigate further but don't really know how to go about it, so if there > are any simple pointers about how to investigate further I'll hop to it. = For > instance I'm not sure why URL encoding gets into the LDAP results picture= at > all, and where it might be occuring in the code. > I didn't look into the codec part, so I cannot tell you why URL encoding gets into LDAP. Perhaps Alex or Emmanuel could help us here. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_7893_1856739.1127444161286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Norbert,

2005/9/23, Norbet Reill= y <nrhope@gmail.com>:<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Trustin,
 
Just thought I might mention this issue to you as well, as I gather fr= om your postings that you are the MINA guru, and my limitted understanding = of the root cause under this issue leads me to suspect that the MINA level = may be involved in some way.

MINA is just a network application framework.&n= bsp; It doesn't have relationship with escaping IMHO.  You'd better to= look at the LDAP protocol handler and LDAP codec. You can locate them at:<= br>
* protocol-providers\ldap\trunk
* shared\ldap\trunk

I know you guys are= really busy, but if you get a second to scan the issue (and reassign the c= omponent if reqd) that would be great. I'm happy to investigate further but= don't really know how to go about it, so if there are any simple pointers = about how to investigate further I'll hop to it. For instance I'm not sure = why URL encoding gets into the LDAP results picture at all, and where it mi= ght be occuring in the code.

I didn't look into the codec part, so I cannot = tell you why URL encoding gets into LDAP.  Perhaps Alex or Emmanuel co= uld help us here.

Trustin
--
what we call human n= ature is actually human habit
--
http://gleamynode.net/ ------=_Part_7893_1856739.1127444161286--