Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <472974EF.3090003@wso2.com>
Date: Thu, 01 Nov 2007 12:10:47 +0530
From: Kaushalye Kapuruge <kaushalye@wso2.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060713)
MIME-Version: 1.0
To: Apache AXIS C User List <axis-c-user@ws.apache.org>
Subject: Re: issue 731 - please have a look
References: <471A0729.7030309@9elements.com>
 <471D7129.6050803@wso2.com>	 <471DA9E9.6020100@wso2.com>
 <471DC2FF.1090107@wso2.com>
 <489947c0710250643we9ab528xf9d8a7f49c1d239d@mail.gmail.com>
In-Reply-To: <489947c0710250643we9ab528xf9d8a7f49c1d239d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Subra and others,
I've committed the new code to calculate the base64_decode_len. Please 
find the JIRA here[1]
The code works fine. And Manjula has done successful interop tests using 
the new code.
You can use following to calculate the decoded length of a char buff. 
Let us know if you are still experiencing the problem.
int axutil_base64_decode_len( const char *bufcoded)
Cheers,
Kaushalye
[1]https://issues.apache.org/jira/browse/AXIS2C-731

Subra A Narayanan wrote:
> Hello,
>
> So what is the proposed solution to this problem? Is the code going to 
> be changed so that apr_base64_decode_len() always returns the correct 
> length or should developers use [axutil/apr]_base64_decode() to get 
> the exact length?
>
> I use the apr_base64_decode_len() function to allocate memory for 
> attachment recvd via the webservice and that introduces garbage 
> characters in the end as the len function always returns a value 
> greates than the actual length.
>
> Subra
>
> On 10/23/07, *Dumindu Pallewela* <dumindu@wso2.com 
> <mailto:dumindu@wso2.com>> wrote:
>
>     Kaushalye Kapuruge wrote:
>     > Samisa Abeysinghe wrote:
>     >> Mark N��ler wrote:
>     >>> hello users,
>     >>>
>     >>> on 26.09.2007 Royston Day found an issue,
>     >>> i just correct my svn-code localy.
>     >>>
>     >>> Can someone have a look - 4 me Royston is
>     >>> right.
>     >>>
>     >>> https://issues.apache.org/jira/browse/AXIS2C-731
>     <https://issues.apache.org/jira/browse/AXIS2C-731>
>     >> I think Rampart folks uses base64 encoding. Can someone using
>     rampart
>     >> please verify that the proposed code it correct.
>     >>
>     > I tried with the new code and it worked fine for all the
>     scenarios in
>     > Rampart/C. But I'm concerned about the interoperability. So it's too
>     > early to say that new implementation is correct unless it is
>     > inter-operable with other implementations. I'll update on that
>     later.
>
>     axutil_base64_decode_len() is the same implementation as that of the
>     apr_base64_decode_len() found in libapr. AFAIK, this does not
>     returns the exact decoded length of the encoded string, but returns
>       at least as many number of bytes that is necessary. Exact length
>     is anyway returned by the [axutil/apr]_base64_decode().
>
>     Thus, if the length returned from the proposed code is correct,
>     there should be no problems with interoperability.
>
>     -Dumindu.
>
>     --
>     Dumindu Pallewela
>     http://blog.dumindu.com
>     GPG ID: 0x9E131672
>
>     WSO2 | http://wso2.com | "Oxygenating the Web Service Platform"
>
>
>


-- 
http://blog.kaushalye.org/
http://wso2.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org